A CSS cubic-bezier easing curve is defined by four numbers — x1, y1, x2, and y2 — and nearly every mistake when generating one traces back to misunderstanding what those numbers actually control. The two x values describe input time and must stay inside the closed range zero to one, because CSS rejects any cubic-bezier() value whose x coordinates fall outside that window. The two y values describe output progress and are accepted anywhere from minus ten through ten, which is what produces anticipation before motion or overshoot past the end. Add the fixed start point (0, 0) and the fixed end point (1, 1) and you have the entire grammar of the timing function: a parametric curve that maps the elapsed fraction of duration to animated progress. Once those four rules are clear, most of the typical generation errors stop feeling mysterious and start being predictable. The remaining work is confirming the curve reads correctly in a chart, a sample table, an animated preview, and the actual component you ship.
The Mistakes That Break a CSS Cubic Bezier
The mistakes that break a cubic-bezier fall into a small set, and each one is tied to a specific rule in the W3C CSS Easing Functions Level 1 specification.
The first is the out-of-range x. Many tools and tutorials let you drag control handles anywhere on screen, and the curve still looks plausible. CSS does not look at plausibility — it parses the value and the browser discards anything whose x1 or x2 falls outside [0, 1]. The animation then either runs as linear or, depending on the engine, falls back to the default ease. Either way, the curve you designed is gone.
The second is the parameter-versus-time trap. A cubic-bezier curve is parametric, not a function of elapsed time. The curve parameter t runs from 0 to 1, but the x coordinate at t equals 0.5 is rarely 0.5 unless the control points are arranged to make that true. Reading the chart as if the horizontal axis were "time progressed" silently lies about where the animated value actually is.
The third is shipping a keyword without checking the numbers behind it. Linear, ease, ease-in, ease-out, and ease-in-out all correspond to specific control points defined by the CSS spec. Picking a keyword and pasting it into production without checking the values means a teammate cannot recreate the curve from the source. If the spec changes, or the keyword gets parsed unexpectedly, the timing drifts.
The fourth is trusting the chart when y exceeds one. The square frame plots the parametric curve, and a deliberately extreme y value can extend outside the visible area. A glance might tell you the curve was clipped to the square; the moving preview still uses the actual value, so the element really does overshoot.
The fifth is treating cubic-bezier() as a transition shorthand. It is one property: transition-timing-function. The duration, delay, property, and iteration count still have to be set, and the value only contributes one piece of the overall animation.
How the CSS Cubic Bezier Generator Prevents Them
The CSS Cubic Bezier Generator is built around exactly those rules, so it catches most of them automatically. x inputs are constrained to the valid CSS range, and finite y values from minus ten through ten are accepted. The interface will not produce a value that CSS rejects for invalid coordinates.
The keyword presets follow the standardized control points from the W3C specification, which MDN's cubic-bezier reference documents independently. Choosing a preset does not write the keyword back into the declaration — the visible output always exposes all four numbers, rounded to three decimals. That makes the value recordable, comparable, and modifiable without hidden defaults. Numbers retain full JavaScript precision inside the calculation; rounding happens only when the declaration is serialized.
The keyword-to-control-point mapping is worth keeping on hand when you read or hand off code.
| Keyword | Standard cubic-bezier value |
|---|---|
| linear | cubic-bezier(0, 0, 1, 1) |
| ease | cubic-bezier(0.25, 0.1, 0.25, 1) |
| ease-in | cubic-bezier(0.42, 0, 1, 1) |
| ease-out | cubic-bezier(0, 0, 0.58, 1) |
| ease-in-out | cubic-bezier(0.42, 0, 0.58, 1) |
For the y values, the interface accepts overshoot and anticipation, but the chart keeps a stable zero-to-one frame for comparing ordinary timing curves, so a deliberately extreme y extends outside the visible square. The sample table and animated preview still use the actual computed easing. If overshoot matters, inspect the moving element and the numeric samples rather than assuming a clipped chart means the value was clamped.
Generate a Valid Cubic Bezier in Three Steps
- Pick a preset or set the four numbers. Start with a standard easing keyword if the curve is for general UI motion, or enter x1, y1, x2, and y2 directly if you already know the shape you want. The five presets are linear, ease, ease-in, ease-out, and ease-in-out, each loading their standardized control points from the W3C specification. If you choose a preset, the visible declaration still shows all four numbers rather than the keyword itself, so you can record exactly what the browser will use. To customize, drag the handles or type values into the four input fields; x values are constrained to the valid CSS range and y values accept anything from minus ten through ten.
- Read the graph, the samples, and the Run preview together. A well-shaped curve on the chart is not enough — the sample table reports the actual progress the animated value reaches at 0, 0.25, 0.5, 0.75, and 1.0 of elapsed input. If the sample at 50 percent is far from 0.5, the curve is accelerating or decelerating aggressively around the halfway mark and the chart alone will not show that. The Run preview toggles a circle across two horizontal positions using a 900 millisecond transform transition and the exact generated easing string, so you can see the timing applied to real motion. Repeated clicks let you compare forward and reverse travel.
- Copy the declaration and test it on the real component. Use the copy control to write the complete transition-timing-function declaration, including its semicolon. Paste it into the production stylesheet on the actual property, distance, and duration you intend to ship. The preview demonstrates timing only; distance, duration, rendering cost, and surrounding motion all change how the easing feels. A 900 millisecond transform in the preview does not predict how a 250 millisecond opacity change will feel, and the production context might surface issues the preview cannot.
Read the Sample Table Before You Trust the Curve
The sample table is the part of the interface that answers the question the chart cannot: how far has the animated value actually progressed when a given fraction of time has passed. For each of the five input points — 0, 0.25, 0.5, 0.75, and 1.0 — the solver finds the curve parameter that produces the requested x coordinate and then evaluates y. It first uses bounded Newton iterations and finishes with bisection when necessary. This avoids the common mistake of treating the curve parameter as elapsed time even when the x control points make those values different.
The reason this matters is the parameter-versus-time trap from earlier. On a curve where x1 = 0.42 and x2 = 0.58, the half-way mark in elapsed time maps to a parameter value whose x coordinate is 0.5 — and the y coordinate at that parameter is the actual animated progress. The chart shows the full curve in parametric form; the sample table collapses it to the five values you most often need to check.
If a curve looks balanced on the chart but the sample table shows the value at 0.25 already past 0.5, the curve front-loads motion and the perceived timing will not match the visual shape. Treat the chart as orientation and the sample table as ground truth before you copy a declaration into production.
Test the Easing in the Real Component Before Shipping
A cubic-bezier value that looks right in the preview can still feel wrong in production because the preview demonstrates timing, not performance. Distance changes the perceived speed, duration changes the weight of the easing, and the animated property changes how the curve reads — a transform translate responds to easing differently from opacity or background-color.
A short distance combined with aggressive overshoot can make a control appear to leave its container and snap back, which surfaces layout assumptions that did not exist at full size. A long duration with subtle acceleration feels gentle in isolation but jarring inside a busy interface. A curve that overshoots past 1.0 must be checked against the actual content the element overlays, because overshoot can reveal content that was expected to remain clipped. For a deeper look at what is permitted once y leaves the standard range, the guide on y values leaving the 0–1 range in CSS cubic-bezier() walks through the same constraint.
Also note that the generator does not emit keyframes, spring physics, linear() stop lists, steps(), duration, delay, iteration count, or a full transition shorthand — it produces a single cubic-bezier timing function, which keeps the output predictable and easy to audit but means the rest of the animation is still your responsibility. If the goal is a complete transition line, you still have to assemble the property, duration, delay, and any reduced-motion fallback yourself.
Match the Curve to Accessibility and Reduced Motion
Reduced-motion preferences are part of the same shipping test. If a cubic-bezier is non-essential decoration, respect prefers-reduced-motion and either shorten the duration, remove the easing, or eliminate the animation entirely. A valid curve is not automatically accessible, performant, or appropriate, and shipping one without checking focus, pointer behavior, and reduced-motion fallback is one of the more common accessibility mistakes.
Large overshoots can make controls appear to reverse, leave their container, or reveal content that was expected to remain clipped. Rapid oscillation can trigger vestibular discomfort in users who have asked the operating system to reduce motion. Important state changes should remain understandable without motion — meaning the underlying UI must work even when the animation is removed entirely.
Keep focus order predictable while an element is transitioning, and check that pointer events on the moving element either behave correctly or are temporarily disabled. A cubic-bezier controls timing; it does not control whether the animation should exist in the first place, and treating it as a substitute for those decisions is the last mistake worth removing from your workflow.