A CSS cubic-bezier() value becomes invalid the moment either x control coordinate falls outside the closed range of zero to one, which is the most common reason a custom easing curve silently fails in the browser. When the value is invalid, browsers ignore the entire declaration and fall back to the default ease keyword, so the animation still runs but with timing the developer did not intend. Other problems come from misunderstanding what the curve is plotting: the x axis represents input time, while the y axis represents the animated value, and the curve parameter t is not the same as elapsed time except for symmetric control points. Misreading a 50% sample as "halfway through the curve at t = 0.5" instead of "halfway through time" produces an apparent mismatch. A generated curve can also be technically valid yet feel wrong — extreme y values create overshoot that takes content outside its container, or anticipation that reverses briefly before settling. Troubleshooting means isolating which of these problems applies, then verifying the fix with controlled inputs, numeric samples, and a real-world preview.
What Usually Goes Wrong When You Generate a CSS Cubic Bezier
Most cubic-bezier() problems fall into one of five recognizable patterns, and recognizing the pattern narrows the fix considerably.
The first and most common is an out-of-range x coordinate. CSS defines a cubic-bezier() value as invalid whenever x1 or x2 lies outside the closed interval [0, 1]. The browser does not warn you; it silently falls back to the default ease keyword. The animation still plays, but with timing you never wrote.
The second is confusion between the curve parameter t and elapsed input time. The numeric sample table in the generator exposes five sample points at input values 0, 0.25, 0.5, 0.75, and 1. Because the x axis is elapsed time and not the parameter, the 50% row of the table is rarely the y value at t = 0.5 except for symmetric control points. Treating those two as the same is the source of "my curve does not match what I expected" reports.
The third is a valid curve that feels wrong in practice. Y values outside [0, 1] create anticipation below zero or overshoot above one, and extreme values can pull a control out of its container, flip focus order, or fight with reduced-motion preferences.
The fourth is putting the declaration on the wrong CSS property. A cubic-bezier() written inside @keyframes is silently ignored; it belongs on transition-timing-function or animation-timing-function, where the timing function is consumed by the transition or animation engine as a whole.
The fifth is a copy-paste issue where a leading keyword is preserved instead of the full numeric form. The CSS Cubic Bezier Generator always exposes all four numbers after a keyword is chosen so the result can be recorded and modified without hidden defaults.
How to Fix a CSS Cubic Bezier Problem Step by Step
- Open the CSS Cubic Bezier Generator and either pick a standard easing preset or type the four control coordinates you were already using.
- Confirm the generator accepts the values. The x inputs are constrained to the valid CSS range, so any out-of-range x is rejected at the input level rather than producing a silently invalid declaration.
- Read the numeric sample table at inputs 0, 0.25, 0.5, 0.75, and 1. If the value you expected at "halfway through" does not appear at the 0.5 row, you were probably thinking in terms of the curve parameter instead of elapsed time.
- Press Run preview to watch the circle move with a 900-millisecond transform transition using the exact generated easing. Repeat the click to compare forward and reverse motion.
- Copy the complete declaration, including its trailing semicolon, then paste it into the transition-timing-function or animation-timing-function of the real component.
- Test with the actual property, distance, duration, and reduced-motion setting, because the preview demonstrates timing only and not production performance under every workload.
Why x1 and x2 Must Stay Between Zero and One
According to the W3C CSS Easing Functions Level 1 specification, x1 and x2 are input-time positions: they describe how far along the animation the two intermediate control points sit. CSS requires both to remain in the closed interval [0, 1] because input time must move monotonically from zero to one, and an x outside that range would force the curve to loop back in time, which the timing model cannot represent. The result is an invalid cubic-bezier() value, and the browser's fallback behavior is to ignore the entire declaration and use ease instead.
Y values are different. They are output progress, not input progress, so the spec allows y1 and y2 to leave [0, 1]. A negative y1 produces anticipation — the animated value briefly moves opposite to the final direction — while a y2 above one produces overshoot, where the value travels past its final position and settles back. Both are legitimate techniques for elastic or spring-style motion, but extreme values should always be tested in the final interface. The CSS Cubic Bezier Generator accepts finite y values from minus ten through ten, which covers any realistic easing intent without producing non-finite numbers that the browser could reject.
Two external sources confirm these constraints: W3C CSS Easing Functions Level 1 defines the validity rule, and MDN's cubic-bezier() reference documents the browser-side fallback behavior and shows matching examples.
Why the 50% Sample Is Not the Value at t = 0.5
A cubic Bézier curve in 2D space is parameterized by a single variable t that runs from zero to one. At t = 0 the curve is at progress (0, 0); at t = 1 the curve is at progress (1, 1). Inside that range the curve traces a smooth path defined by the two control points. It is tempting to read the curve as if t were elapsed time, but it is not. The browser drives animation by input time on the x axis, and then looks up the y value that corresponds to that x. The mapping between x and t depends entirely on where the control points are placed.
The generator exposes this distinction directly. For each sample input at 0, 0.25, 0.5, 0.75, and 1, the solver first finds the t value whose x coordinate matches the requested input, then evaluates y at that t. The implementation uses bounded Newton iterations and falls back to bisection when needed, which avoids the trap of treating the curve parameter as elapsed time. That is why a row at input 0.5 is meaningfully different from "the curve at t = 0.5" unless the control points are symmetric.
If you are trying to match a feeling you remember from another tool, look at the 0.5 row of the sample table first. That row answers the practical question: how far has the animated value progressed when half the duration has elapsed?
Reading the Keyword Mappings Without Losing Them
CSS defines five easing keywords, and each keyword has an exact cubic-bezier() equivalent. The values below come from the W3C CSS Easing Functions Level 1 specification and are preserved as executable reference data inside the generator. Choosing a keyword in the interface does not output the keyword itself; it loads the four numbers so the declaration can be recorded and tuned.
| Keyword | cubic-bezier(x1, y1, x2, y2) | Common use |
|---|---|---|
| linear | cubic-bezier(0, 0, 1, 1) | Constant-speed motion, loading bars |
| ease | cubic-bezier(0.25, 0.1, 0.25, 1) | Default, gentle acceleration then deceleration |
| ease-in | cubic-bezier(0.42, 0, 1, 1) | Slow start, useful for elements leaving the screen |
| ease-out | cubic-bezier(0, 0, 0.58, 1) | Fast start, elements arriving on screen |
| ease-in-out | cubic-bezier(0.42, 0, 0.58, 1) | Symmetric slow start and end |
If your "broken" curve was produced by typing a keyword into the wrong property, swap to the equivalent numeric form above and the issue usually disappears.
Testing the Generated Curve in Your Real Interface
A 900-millisecond transform preview in the generator demonstrates timing only. It cannot tell you how the easing will feel under the actual workload of your page. Distance, duration, the property being animated, the rendering cost of that property, the input device, and surrounding motion all change the perceived smoothness. A valid curve is not automatically accessible, performant, or appropriate.
When troubleshooting, run the real component with the candidate easing at its final duration and property. Check focus and pointer behavior while the element is transitioning, because motion can move focus rings off-screen or trap pointer events mid-animation. Respect prefers-reduced-motion: if the animation is not essential, drop it or shorten it dramatically when the user has requested reduced motion. For more on recovering from a curve that looks right in the tool but wrong in production, see Fix a Wrong Result After You Generate a CSS Cubic Bezier.
Two more issues show up at this stage. The first is browser fallback: if you see timing identical to ease despite a custom declaration, check that x1 and x2 are inside [0, 1] and that the declaration is on transition-timing-function or animation-timing-function, not inside @keyframes or on the wrong shorthand. The second is clipboard denial: if the browser refuses clipboard access, the generator keeps the declaration visible and selectable, so manual copy still works and the status indicator does not falsely claim success.
When a Valid Curve Still Feels Wrong
Sometimes every constraint is met, every sample is what you expect, and the result still does not feel right. Before re-tuning the curve, check three things that live outside the cubic-bezier() declaration.
The first is duration. The same curve feels different at 200 milliseconds than at 900 milliseconds, because perception of acceleration and deceleration is tied to absolute time. The second is the animated property. transform and opacity are cheap to animate and run on the compositor; animating width, top, or box-shadow triggers more work per frame and can mask the easing you chose. The third is interaction context. A menu that opens with overshoot may be charming on hover but disorienting on first paint or on small screens.
When in doubt, return to the generator with a specific symptom in mind: "too aggressive at the end," "no anticipation," "does not decelerate." Tune the relevant control point, watch the sample table change, and re-test on the real component. That loop — diagnose the symptom, adjust one coordinate at a time, verify in production — is the practical answer to most cubic-bezier() troubleshooting questions.
Related reading: How Is Knob Travel Distance Calculated: CSS Toggle Switch.