The CSS Cubic Bezier Generator returns four artifacts every time you adjust or load a curve: a copy-ready `cubic-bezier(x1, y1, x2, y2)` declaration, the parametric curve plotted in a zero-to-one frame, five numeric progress samples, and a 900 ms moving preview, all of which recalculate locally in your browser. The four numbers you edit or load from a preset control how the curve bends between the fixed start point (0, 0) and the fixed end point (1, 1); the tool immediately turns those numbers into those four artifacts, so the declaration you carry into your stylesheet and the three diagnostic artifacts that confirm its behavior are produced in lockstep. Nothing about your curve, your CSS, or your interactions is uploaded, stored, or sent to an animation service, which means you can experiment freely without leaving residue behind. The declaration is the only artifact you paste into real CSS; the graph, samples, and preview exist so you can confirm that what you are about to paste behaves the way you expect at the actual duration and property you plan to animate. Because the x coordinates represent elapsed input time, the generator constrains x1 and x2 to the closed range zero through one and accepts finite y values from minus ten through ten, preserving CSS's validity rule for input time while still letting you push the output toward anticipation or overshoot.
The CSS Declaration You Copy
The primary artifact is the timing-function string itself, formatted as `cubic-bezier(x1, y1, x2, y2);` with a trailing semicolon so it can be dropped straight into a stylesheet without further editing. The numbers are rounded to three decimal places only when they are serialized for display; the internal calculation keeps full JavaScript numeric precision, which means the values you see are the values the browser will receive. Even when you start from a CSS keyword such as `ease`, `ease-in`, `ease-out`, or `ease-in-out`, the visible declaration exposes all four numbers from the standardized cubic-bezier mapping defined by CSS Easing Functions Level 1 rather than re-emitting the keyword. That choice keeps the declaration recordable, comparable, and editable without hidden defaults hiding inside the tool's own shorthand, and `linear` maps to the literal coordinates zero, zero, one, one so it stays consistent with the keyword buttons.
The output is intended for `transition-timing-function` or `animation-timing-function`. It is not a full transition shorthand, so you still need to choose the animated property, duration, delay, iteration count, and any reduced-motion fallback yourself. The Copy CSS button writes the complete declaration including the semicolon; if your browser denies clipboard access, the string remains visible and selectable so you can still capture it manually.
The Curve Graph and What It Shows
The square chart plots the parametric cubic Bézier curve from the fixed start (0, 0) to the fixed end (1, 1). Because the start and end are anchored, the four editable numbers only move the two intermediate control points; the graph itself never shifts its frame. Standard easing keywords stay entirely inside the chart, so visual comparison against the line of identity (the diagonal from bottom-left to top-right) gives you an immediate sense of whether your curve accelerates early, decelerates late, or pushes past linear at any point.
A deliberately extreme y value, however, can extend the curve outside the visible square. The chart deliberately keeps a stable zero-to-one frame so that ordinary timing curves can be compared cleanly, which means the curve is not clipped when it overshoots; the actual computed easing is still what the sample table and the moving preview animate. If overshoot matters to your design, inspect the moving element and the numeric samples rather than assume that a curve running off the edge has been clamped to the chart frame. The graph is a comparison surface, not a hard boundary on the math.
The Numeric Progress Samples
The sample table answers a question the control-point diagram alone cannot answer precisely: how far has the animated value progressed when a given fraction of time has passed? For each input at zero, 0.25, 0.5, 0.75, and one, the solver finds the curve parameter that produces the requested x coordinate and then evaluates y at that parameter. The solver first uses bounded Newton iterations and finishes with bisection when necessary, which avoids the common mistake of treating the curve parameter as elapsed time even when the x control points make those values different. The independent validation layer rechecks x and y constraints before the output is produced, so the samples you see have already passed a separate consistency check.
This is also why the sample at fifty percent is not always the curve value at t equals 0.5. CSS timing uses elapsed input progress on the x axis, so the solver must find the parameter whose x coordinate is 0.5 before evaluating y. If you want to compare two curves at the same wall-clock fraction, the sample table is the place to do it. MDN's cubic-bezier reference documents the same constraint from the browser side, which is why previewing against a real component is the most reliable final check.
The Run Preview Motion
The Run preview toggles a circle between two horizontal positions using a 900 millisecond transform transition and the exact generated easing string. Click it once to watch the motion play forward; click it again to watch it return, which gives you an immediate comparison of how the easing reads in both directions. Repeated clicks let you scrub through the curve and confirm that the perceived timing matches what the graph and the samples describe.
The preview is intentionally limited. It demonstrates timing, not production performance under every workload, so a real component can feel different when distance, duration, property, rendering cost, input device, or surrounding motion changes. Treat the preview as a sanity check rather than a final test, and always confirm the declaration inside the actual interface where it will run, respecting reduced-motion preferences where animation is not essential to comprehension.
How to Get a Valid Result in Three Steps
- Choose a standard easing preset or enter x1, y1, x2, and y2 control coordinates in the CSS Cubic Bezier Generator. The five keyword buttons load their W3C-defined cubic-bezier equivalents, and the input fields enforce x between zero and one so the curve stays valid by construction.
- Review the graph, numeric progress samples, and Run preview motion for the intended timing. Check that the curve shape matches what you want, that the five numeric samples look reasonable at each input fraction, and that the previewed motion feels right in both directions.
- Copy the complete CSS declaration and test it on the real property, distance, and duration. Paste it into `transition-timing-function` or `animation-timing-function`, confirm the motion in the final component, and respect reduced-motion preferences where animation is not essential.
Limits and Boundaries of the Output
The generator focuses on a single cubic-bezier timing function, which is why the output stays predictable and easy to audit. It does not generate keyframes, spring physics, linear() stop lists, steps() timing, duration, delay, iteration count, or a full transition shorthand. Those remain choices you make in your stylesheet or animation pipeline. If you need a different timing primitive, the cubic-bezier tool is not the place to look for it.
CSS also permits curves that are technically valid but unpleasant or confusing in practice. 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, so keep important state changes understandable without motion, avoid rapid oscillation, and check focus and pointer behavior while an element is transitioning. If you are unsure whether your specific y values are actually allowed to leave the zero-to-one band, the guide on whether y1 or y2 can leave the 0–1 range walks through the exact CSS validity rule and the visible behavior you should expect from extreme y values.
Testing the Declaration in Real Code
Once you have copied the declaration, paste it into a real transition or animation rule against the property you actually want to animate, at the real distance and duration. A 900 ms preview on a small transform is a useful starting point, but the same curve applied to a 300 ms opacity fade, a long translate, or a height interpolation can read very differently. When the production timing matters, the most reliable way to confirm the result is to test the curve on the real component, in the real layout, with real interaction. For a verification-first walkthrough of how to read each artifact in the output, the output-correctness guide covers the same four artifacts from that angle.
| Output artifact | What it contains | How to use it |
|---|---|---|
| CSS declaration | Complete `cubic-bezier(x1, y1, x2, y2)` string with three-decimal numbers and trailing semicolon | Paste into transition-timing-function or animation-timing-function |
| Curve graph | Parametric curve from (0, 0) to (1, 1) plotted in a fixed zero-to-one frame | Visually compare against the diagonal and against the standard keyword shapes |
| Numeric samples | Five output progress values at input 0, 0.25, 0.5, 0.75, and 1, solved with Newton plus bisection | Audit exact timing at known fractions of the duration |
| Run preview | 900 ms transform transition of a circle between two horizontal positions using your easing | Compare forward versus reverse motion and confirm perceived feel |