Cubic-bezier generator — drag the curve, watch it move, read the numbers

They set the direction and strength of the curve at each end. A cubic Bézier has four points; in CSS the first and last are fixed at (0,0) and (1,1) — nothing has moved when the animation starts, everything has moved when it ends — and you supply the two in between as the four numbers x1, y1, x2, y2. The curve leaves the origin heading straight at the first control point and arrives at the finish coming straight from the second, and how far away each handle sits decides how long the curve keeps going in that direction. That is why dragging the first handle further right, without moving it up, produces a longer stall at the start: the curve is committed to that flat direction for longer.

Because x is time. If a control point’s x could go past 1 or below 0, the curve would bend back on itself, and there would be points in the animation with two different amounts of progress at the same instant — which is not something an element can do. CSS refuses those values outright, and a declaration containing one is dropped. y is a different quantity: it is distance covered, and there is no rule saying an element may not travel past its destination and come back, or set off backwards first. That asymmetry is not an oversight in the spec, and it is not an oversight in this tool either — it is where overshoot and anticipation come from.

Because ease is not symmetrical and ease-in-out is. ease — which is what a transition uses if you never name a timing function — is cubic-bezier(0.25, 0.1, 0.25, 1): it climbs steeply early on and spends the back half of the duration settling. ease-in-out is cubic-bezier(0.42, 0, 0.58, 1), with control points mirrored around the centre, so it accelerates and decelerates by exactly the same amount. Load both from the presets above and read the halfway row of the table: they cross the same point at the middle of the duration and get there along noticeably different paths. ease is the livelier of the two; ease-in-out is the more mechanical.

Something like ease-out — cubic-bezier(0, 0, 0.58, 1) — or a stronger version of it. An element that enters should arrive at rest, which means it needs to be decelerating at the end, and ease-out is the shape that does that. The reverse holds for exits: an element leaving does not need to be watched arriving, so ease-in, cubic-bezier(0.42, 0, 1, 1), lets it accelerate away and get out of the reader’s way. Using the same symmetrical curve for both is the most common reason a set of transitions feels correct in isolation and heavy in use.

No. The duration is fixed by transition-duration or animation-duration, and the timing function only decides how the distance is spread across it. Two elements with the same duration and different easings start together and stop together — the bars above are set up to demonstrate exactly that. What easing changes is the *apparent* speed: a curve that covers 80% of the distance in the first third of its time feels fast even though it has not finished any sooner, because the part the eye tracks is over early.

Almost certainly clipped by a parent with overflow hidden. An overshooting curve moves the element past its final position and back, so for a few frames it is further along than the layout expects — and if an ancestor is clipping, those frames are the ones that disappear. The other regular cause is overshooting a property that cannot exceed its own bounds in a visible way: opacity above 1 and below 0 is clamped, so an overshoot on a fade does nothing at all. Overshoot belongs on transform, where there is room for it.

It works wherever a value is being interpolated, which excludes properties that jump rather than blend. `display` and `visibility` change in a single step; a background-image swapped for a different gradient does not blend either. For everything that does interpolate — transform, opacity, colour, lengths — the timing function applies to the interpolation and works the same way. Note that easing is applied per property, so two properties on the same element can carry different curves, and in a keyframe animation the timing function applies between each pair of keyframes rather than across the whole sequence.

They are the other two shapes of timing function, and neither is a Bézier. steps() splits the duration into a fixed number of jumps, which is how a sprite-sheet animation or a deliberately mechanical counter is built — there is no in-between state at all, so no curve could express it. linear() is newer: it takes a list of progress values and joins them with straight segments, which lets it approximate a spring or a bounce with several direction changes, something a single cubic Bézier with two control points cannot do. Check its support against your own browser targets before shipping it — this page will not make that claim on your behalf.

The value is interchangeable, but where it applies is not. On a transition the curve spans the whole change, start to finish. On a keyframe animation it spans each pair of adjacent keyframes, so an animation with four keyframes and one timing function actually runs that curve three times — accelerating and decelerating at every stop along the way, which is rarely what anyone means. If you want a single curve across a multi-keyframe animation, either reduce it to two keyframes or set a per-keyframe timing function of linear on the intermediate ones so they do not each ease again.