A CSS cubic-bezier easing curve is defined by four control numbers — x1, y1, x2, y2 — placed between two fixed endpoints at (0, 0) and (1, 1), and the W3C CSS Easing Functions Level 1 specification treats the two x coordinates as input-time fractions that must stay between 0 and 1, while the two y coordinates describe output progress and may fall outside that range to create anticipation or overshoot. To compare approaches to generate CSS cubic-bezier timing functions means weighing the visibility each method gives you into the curve itself, the numeric progress samples, and the motion you actually feel when the easing is applied to a real property. The most direct comparison comes down to four practical questions: do you see the curve shape, can you sample progress at known input fractions, does the preview use the actual generated easing on a real element, and can you copy a standards-compatible declaration without guessing or doing mental arithmetic. A dedicated interactive generator satisfies all four at once, where hand-coding or copying from a cheat sheet usually satisfies one or two. The rest of this article lines up those methods side by side and walks through the workflow that closes the gap between "a curve that looks right" and "a declaration that performs predictably in production."
What a CSS cubic-bezier timing function actually controls
CSS evaluates a cubic-bezier easing by treating input time as the x coordinate and animated progress as the y coordinate, then walking the parametric curve from (0, 0) to (1, 1). The four numbers you write do not move those endpoints; they only shape the path between them. Per W3C CSS Easing Functions Level 1, x1 and x2 describe input-time positions, so both must stay inside the closed interval [0, 1] or the declaration is invalid. y1 and y2 describe output progress, and the spec allows them to fall below 0 or above 1 — that is how curves create anticipation, where motion pulls back before going forward, or overshoot, where motion goes past the final value before settling.
The five standardized keywords defined in the same specification expand to numeric cubic-bezier declarations rather than being handled as separate cases. MDN's cubic-bezier() reference documents the same mappings. Even when you only need a plain ease-in-out, the engine still resolves your keyword into the four numbers listed later in this article, and that resolution is what every generation method ultimately has to deliver.
Five common approaches to generating a CSS cubic-bezier
You can arrive at a cubic-bezier declaration through five reasonably common paths.
- Hand-editing the four numbers in your stylesheet. You type cubic-bezier(0.25, 0.1, 0.25, 1) directly into your CSS, tweak it when the motion feels off, and reload the page. This is the path with the least tooling and the most trial and error.
- Copying values from a keyword cheat sheet. A reference page lists the standardized mappings for linear, ease, ease-in, ease-out, and ease-in-out, and you paste those numbers into your code. This is fast when you only need a standard preset.
- Recording motion in browser DevTools. Chromium-based DevTools let you drag control handles inside the animation panel and read the resulting numbers. The shape is visible, but you generally do not see sampled progress at known input fractions.
- Borrowing numbers from an easing curve library. Community sites publish popular curves like ease-in-out-quart and ease-out-back. You get a community-tested value, but you still cannot sample progress at arbitrary inputs without doing the math yourself.
- Using a dedicated interactive generator. A tool such as the CSS Cubic Bezier Generator exposes the curve, the four control numbers, sampled progress at five input fractions, and a real-element preview that runs the actual easing string. The workflow behind that tool is covered step by step below, and a deeper walkthrough of the same approach lives in How to Use Cubic Bezier CSS for Custom Easing.
How those approaches compare side by side
| Approach | Curve visible | Samples progress numerically | Previews the actual easing | Output is standards-valid |
|---|---|---|---|---|
| Hand-editing in code | No | No | Only by reloading the page | Manual check required |
| Keyword cheat sheet | Sometimes | No | No | Yes (standardized values) |
| DevTools animation panel | Yes | Limited | Limited | Yes |
| Easing curve library | Sometimes | No | No | Yes (community-maintained) |
| Interactive generator | Yes | Yes (five fixed inputs) | Yes (real element, real easing) | Yes (validated in the tool) |
The rightmost column matters more than the others. A generator that lets you move the handles freely but never checks whether x1 or x2 drifted outside the valid interval is closer to hand-editing than to a standards-respecting tool. Validation lives in the same layer as numeric sampling: the math has to confirm the curve is well-defined before the declaration leaves the page.
Generate a curve and compare it against the keyword presets
- Open the CSS Cubic Bezier Generator and pick one of the five keyword buttons — linear, ease, ease-in, ease-out, or ease-in-out. The four control numbers load from the W3C CSS Easing Functions Level 1 reference values rather than the keyword itself, so the visible declaration always exposes all four numbers.
- Read the graph and the sample table. The graph plots the parametric curve inside a fixed zero-to-one square, and the sample table lists the y value reached when x is 0, 0.25, 0.5, 0.75, and 1. These are the numbers you compare against any custom curve you build.
- Click Run preview to watch a circle toggle between two horizontal positions over 900 milliseconds with the exact generated easing on a real transform transition. Click again to compare forward and reverse motion under the same easing.
- Adjust x1, y1, x2, and y2 directly. The interface constrains x inputs to the valid CSS range, accepts finite y values from minus ten through ten, and refuses to produce output when x falls outside [0, 1]. The graph, sample table, and preview update immediately.
- Inspect a deliberately extreme y value, for example y2 = 1.4, and read the sample table to confirm overshoot before trusting the curve. The chart keeps a stable zero-to-one frame for ordinary timing curves, so an overshoot can extend outside the visible square; trust the samples and the preview, not the chart bounds.
- Copy the declaration once the curve matches the timing you want, then paste it into the real transition with the property, distance, and duration it will run on. The generator outputs only transition-timing-function, so duration, delay, property, and reduced-motion behaviour stay your responsibility.
Why samples are read at input fractions, not at curve parameter t
A common mistake when reading easing curves is to look at the y value where the curve parameter t equals 0.5 and assume that is the progress reached at 50 percent elapsed time. CSS timing does not work that way: x is the elapsed input progress, so the sample at 50 percent is the y value reached at whichever curve parameter t makes x equal 0.5. For symmetric keyword presets such as ease-in-out, the result is similar, but for curves with skewed control points, the difference can be visible in the sample table.
The CSS Cubic Bezier Generator handles this distinction by solving the inverse: for each requested input (0, 0.25, 0.5, 0.75, 1), it finds the curve parameter t whose x coordinate equals that input, then evaluates y at that t. The internal solver uses bounded Newton iterations and falls back to bisection when needed, which avoids the common shortcut of treating t as elapsed time even when the control points make those values different. That is also why the same tool warns, in its FAQ, that the sample at 50 percent is not always the curve value at t equals 0.5 — the constraint x is input time forces an inverse solve, not a direct lookup.
Where each approach breaks down
Hand-editing fails silently. You change y2 from 0.9 to 1.1 expecting a small overshoot, but the animation now takes longer than the transition duration suggests because the curve spends more time above 1. There is no chart, no table, and no preview to tell you why.
Cheat sheets fail when you need anything beyond what they list. A reference table that maps five keywords to five sets of numbers cannot tell you what happens at x = 0.5 for a custom curve, nor can it help you build a curve whose y1 is 0.42 and whose y2 is 0.58 for a sharp ease-in-out.
DevTools panels fail when you need portable output. The shape you recorded lives inside the DevTools session, and copying the numbers back into your editor takes more steps than a one-click copy from a generator that always keeps the declaration visible.
Easing libraries fail when you need to verify what their values produce at non-keyword inputs. The published curves are tested by their authors, but you have no way to read off the progress at arbitrary t without re-deriving the math.
An interactive generator fails when you treat its chart as authoritative for overshoot. The chart frame is fixed at [0, 1] so that ordinary timing curves can be compared cleanly, and a deliberately extreme y value can extend outside that square without the chart clipping the curve. Always confirm overshoot in the sample table or the running preview rather than assuming a clipped chart means the value was clamped — the same point the related guide Can y1 or y2 Leave the 0–1 Range in CSS cubic-bezier()? makes about y-coordinate validity.
Quick reference — standardized keyword presets
| Keyword | Control points per W3C CSS Easing Functions Level 1 | Feel |
|---|---|---|
| linear | cubic-bezier(0, 0, 1, 1) | Constant speed, no acceleration |
| ease | cubic-bezier(0.25, 0.1, 0.25, 1) | Slight ease-in then settle, the default |
| ease-in | cubic-bezier(0.42, 0, 1, 1) | Slow start, accelerating finish |
| ease-out | cubic-bezier(0, 0, 0.58, 1) | Fast start, decelerating finish |
| ease-in-out | cubic-bezier(0.42, 0, 0.58, 1) | Symmetric acceleration then deceleration |
Use this reference as the baseline for comparison. When a custom curve feels close to ease-in-out, you should be able to read its four numbers and see how far it sits from the standardized row above — that comparison is exactly what the generator is designed to support.