A valid CSS cubic-bezier() easing is defined by four numbers — x1, y1, x2, y2 — and the key comparison you need to make before generating one is between the timing curve you intend to draw and the timing curve your animation actually needs. The two x coordinates describe when each control point's influence takes hold along the elapsed input time, and CSS requires both to remain inside the closed 0–1 interval. The two y coordinates describe how far the animated value has progressed at those moments and may sit below zero or above one, which produces anticipation or overshoot. Because x is locked to the input-time range while y is free to leave the output-progress range, comparing each pair separately is the only way to predict whether the curve will accelerate, decelerate, anticipate, or overshoot without surprises. The CSS Cubic Bezier Generator exposes all four numbers, the parametric curve graph, sampled progress at five input fractions, and a 900-millisecond motion preview, so you can compare what the math says against what the eye sees before committing the declaration to a real component.
The Three Comparisons That Decide Whether a Curve Fits
Most easing problems trace back to three comparisons that never happened during authoring. The first is the curve's intent against the standard CSS keywords. Linear, ease, ease-in, ease-out, and ease-in-out are not magical — each one is a fixed cubic-bezier() with documented control points, and the generator surfaces those mappings as reference data so you can see whether your custom curve is meaningfully different from a preset the browser already understands. The second comparison is the shape of the parametric graph against the numeric sample table. A visually steep curve near the right edge can still produce modest output at 25 percent elapsed time, so judging by the chart alone leads to wrong assumptions about mid-animation progress. The third comparison is the intended feel of the motion (snappy, calm, spring-like, decorative) against the practical risk of overshoot — a y value above one will visibly push the element past its resting position, which can matter for layout containers, clipped content, and accessibility.
Doing these comparisons before you lock in the four numbers prevents the most common failure mode: writing a curve that reads beautifully on paper but feels wrong in the interface because the sampled output at 0.5 input time is not the value the curve parameter t equals 0.5 would suggest. The browser does not animate by walking the curve parameter; it walks input progress along the x axis and looks up the corresponding y.
Standard Keyword Curves vs. Custom Control Points
The W3C CSS Easing Functions Level 1 specification defines five keyword easings, each as a cubic-bezier() with fixed control points. Choosing one of these keywords in the generator does not output the keyword itself; it loads the same numeric curve so the declaration stays auditable. The table below lists every keyword and its standardized mapping, which is the baseline you should compare any custom curve against before deciding whether the extra precision is justified.
| CSS keyword | Standard cubic-bezier() form | Feel |
|---|---|---|
| linear | cubic-bezier(0, 0, 1, 1) | Constant speed, mechanical |
| ease | cubic-bezier(0.25, 0.1, 0.25, 1) | Default, gentle acceleration and deceleration |
| ease-in | cubic-bezier(0.42, 0, 1, 1) | Starts slow, finishes fast |
| ease-out | cubic-bezier(0, 0, 0.58, 1) | Starts fast, finishes slow |
| ease-in-out | cubic-bezier(0.42, 0, 0.58, 1) | Slow at both ends, fast in the middle |
Source: W3C CSS Easing Functions Level 1. The mappings are preserved in the generator as tested reference data rather than accepted from memory, so they remain consistent with the spec.
If your custom curve produces sample values close to one of these rows at 0.25, 0.5, and 0.75 input progress, the keyword will do the same job with less code and broader recognition from anyone reviewing your CSS. If the samples diverge noticeably — for example, a sharper mid-point snap or a visible overshoot at the end — the custom curve is justified.
Read the Curve Against the Numeric Sample Table
The sample table answers a question the graph alone cannot: at each of the five standard input fractions (0, 0.25, 0.5, 0.75, 1), how far has the animated value actually progressed? The solver finds the curve parameter whose x coordinate equals the requested input, then evaluates y at that point. It runs bounded Newton iterations first and finishes with bisection when Newton fails to converge, which matters whenever the x control points make 0.5 input progress correspond to a curve parameter that is not 0.5.
This is the comparison to make whenever a curve looks balanced in the chart but feels lopsided in the preview. For ease-out, the 0.25 input sample sits at roughly 0.38 progress, not 0.25 — the curve has already covered a large fraction of the distance in the first quarter of the time. For ease-in-out, the 0.5 input sample is approximately 0.5 progress but the 0.25 and 0.75 samples sit well away from 0.25 and 0.75 respectively, because the curve stays flat near both ends. Reading the table is the cheapest way to confirm that the curve you are about to copy produces the timing rhythm you want.
Generate and Verify a Cubic Bezier in Three Steps
- Pick a starting point. Load one of the five standard keywords to see a baseline curve, or enter x1, y1, x2, y2 directly if you already have a target in mind. The generator clamps x inputs to the 0–1 range and accepts finite y values from −10 to 10, with the calculation independently validating those limits before producing output.
- Review four views of the same curve. Compare the parametric graph, the five-row sample table, the rounded transition-timing-function declaration, and the Run preview motion. If the chart, the table, and the moving circle all agree, the curve is internally consistent. If they disagree, suspect a mental model mistake: the chart always plots the curve parameter, the table plots elapsed input progress, and the preview shows the actual eased value.
- Copy the declaration and test it in context. Copy CSS writes the complete transition-timing-function line, including the trailing semicolon. If the browser refuses clipboard access, the declaration remains selectable on screen and the status does not claim success. Paste it into your real component, with the actual property, distance, and duration you intend to animate, and click Run repeatedly to compare forward and reverse motion.
Numbers are rounded to three decimal places only when serialized for the copy buffer; the underlying calculation retains full JavaScript numeric precision, so two curves that look identical in the declaration can still differ in the sample table when their unrounded values diverge.
What the Generator Deliberately Does Not Produce
The tool focuses on a single cubic-bezier() timing function so the output stays predictable and easy to audit. It does not generate keyframes, spring physics, linear() stop lists, steps(), duration, delay, iteration count, or a full transition shorthand. You still choose the animated property, how far it moves, how long it takes, and how it behaves under prefers-reduced-motion.
All calculation happens in the browser, and no curve, CSS, or interaction data is uploaded, stored, or sent to an animation service. That separation matters for two reasons. First, it means the preview you see is exactly the curve you copy — there is no remote optimizer quietly smoothing your numbers. Second, it means the tool can offer overshoot up to y = 10 without any risk of a backend misinterpreting extreme values, because nothing leaves your machine.
Test the Declaration on the Real Property, Distance, and Duration
The 900-millisecond Run preview demonstrates timing, not production performance. A real component can feel different when distance, duration, property, rendering cost, input device, or surrounding motion changes. A cubic-bezier tuned for a 300-pixel transform over 600 milliseconds may feel sluggish on a 30-pixel change or frantic on a 1200-millisecond one. Always test the declaration inside the final interface, with the actual paint cost of the property you are animating.
Two extra comparisons belong at this stage. The first is motion against accessibility: large overshoots can make controls appear to reverse, leave their container, or reveal content that was expected to remain clipped. A valid curve is not automatically accessible, performant, or appropriate. Keep important state changes understandable without motion, avoid rapid oscillation, and check focus and pointer behavior while an element is transitioning. The second comparison is against reduced-motion preferences — if the animation is decorative, gate it behind a media query that honors users who request less motion. For browser-oriented behavior and examples on each cubic-bezier keyword, see the MDN cubic-bezier() reference.
For a structured comparison of different authoring approaches before you generate the curve itself, the comparison guide walks through the trade-offs of preset keywords, hand-tuned numbers, and copied community curves side by side.
For a deeper look, see What Beginners Should Know Before a CSS Toggle Switch.