Reverse-engineer a CSS animation: duration, easing and delay, measured
DevTools shows you the rule, if you can find it under three layers of minified class names — and shows nothing when the animation is driven by JavaScript. mvoom measures the animation as it runs, so the curve you get is the one the page actually performs, whether it came from a stylesheet, a library or a loop.
A stylesheet says what was written; the browser does what happened. A transition declared at 300 ms can be overridden by a class added on scroll, a JavaScript library can drive a transform without a single CSS rule, and a spring has no cubic-bezier at all until you fit one. mvoom samples the running value, fits the curve and reports the fit — and says when a curve is deduced rather than declared.
Every recipe carries where it came from: read from the engine, sampled, or written in the markup. That honesty is the difference between a number you can use and a number you have to verify.
- 01Read the piece
Paste the page, pick the element that animates. The read is free.
- 02Open the recipe
Duration, easing as a cubic-bezier, delay, the properties and their keyframes, and whether the value was read or sampled.
- 03Take the code
Buy the piece and the CSS keyframes and the React component are generated from the same measurement.
- The exact cubic-bezier, duration and delay of each animation
- Keyframes with the measured from/to values
- A note on what was declared versus what was deduced
What about spring animations?
A spring is sampled and fitted to a curve you can reproduce with CSS or WAAPI; the recipe says it was fitted. If you need the physical parameters, the sampled keyframes are in the recipe.
Can it read animations behind a hover or a click?
Yes — the read triggers hover and click transitions on the piece and measures what happens.
Reading is free and needs no account. Everything above is what runs today — nothing here is a roadmap.
MEASURE AN ANIMATION →