CSS Cubic Bezier Generator

Features

• Drag either control point on the plane; curve and numbers stay in sync
• Time across, progress up — the animation is faster where the curve is steeper
• The vertical axis may leave the unit square (±0.5 of drag room), which is how overshoot is made
• Seven presets, each labelled with where it belongs (fast-out, entrance bounce, strong fast-out…)
• Names the keyword your curve is equivalent to (ease, linear, ease-out…)
• A playable square preview, so you judge by feel instead of imagining from the curve
• Keyboard operable: focus a handle and use the arrow keys, Shift to accelerate, Alt to fine-tune
• Copies a complete snippet covering both transition and animation usage

How to use

1. Drag the two handles, or load a preset first
2. Press Play and watch the square — feel beats reading the curve
3. Or type values straight into the four inputs
4. Copy the CSS below into your stylesheet

FAQ

What are the four numbers?

The coordinates of two control points: `cubic-bezier(x1, y1, x2, y2)`. The curve always runs from (0,0) to (1,1), and these two points pull it — which is why the editor has two handles rather than four. The horizontal axis is time (start to finish); the vertical is progress (beginning to end).

Why can y leave 0–1?

Because the specification puts no limit on y, and leaving the range is exactly where overshoot comes from: y above 1 means “past the end, then back”; y below 0 means “pull back first, like a stretched band”, which is how the entrance-bounce and big-overshoot presets work. By contrast x must stay within 0–1 — outside that it invalidates the whole `transition` declaration (not ignores it; the entire declaration stops applying), so the editor clamps x while dragging.

What duration should go with the curve?

Tune the duration and the curve together, because the same curve feels entirely different at 200ms and 800ms — which is an argument for a preview that lets you change the duration (this one fixes it at 900ms, deliberately slow so the shape is readable). Rules of thumb: hover feedback 150–250ms, element movement 300–500ms, entrance animations that should feel lively 400–700ms. The more exaggerated the curve, the less it belongs at a short duration — an overshoot compressed into 120ms reads as a glitch.

Does the easing curve affect performance?

Not directly — what decides performance is which property moves (`transform` and `opacity` can be handled on the compositor; `width`, `top` and `box-shadow` trigger layout or paint), not the curve. The curve only affects how it looks. One exception worth knowing: a cubic-bezier is cheap for the browser to evaluate, while `steps()` and physics-based JS animations can become a bottleneck in long lists.