The difference between an interface that feels cheap and one that feels considered is usually a fifth of a second. A button that snaps to its hover colour the instant your pointer touches it reads as abrupt; the same button easing to that colour over two hundred milliseconds reads as finished. That easing is a CSS transition, and for something so small it is remarkable how often I have seen it done wrong, put on the hover state instead of the base state, tuned by trial and error across a dozen refreshes, or applied to a property that cannot animate at all.
A transition is the browser's way of animating the change between two values of a property over time, rather than switching instantly. It is the workhorse behind hover effects, focus states, expanding panels and toggled classes, and it is almost always the first bit of motion anyone adds to a project. But the shorthand crams four values into one line in a fixed order, the timing function is the part that determines how the motion feels, and there is a well-known cliff people fall off when they try to fade something in from display: none. Building the transition where you can see it play saves all of that.
The CSS Transition Generator lets you pick a property, set the duration and delay in milliseconds, and choose a timing function from the CSS keywords and a set of curated cubic-bezier curves. You can stack several transitions into one shorthand, and a trigger button plays the motion on a live preview element so you feel the easing before you commit to it. The exact declaration sits in a copy-ready box below.
TL;DR: A CSS transition animates the change between two values of a property over a set duration. It belongs on the base state, not the hover state, so the element eases in both directions. The shorthand order is property, duration, timing-function, delay. You cannot transition
display, because it has no intermediate values, and you should prefer animatingtransformandopacityfor smooth performance. This generator exposes every part with a live hover preview, supports multiple layers, and emits clean CSS. It runs entirely in your browser with no signup.
What problem does a CSS transition generator solve?
The hard part of a transition is not the syntax; it is that you cannot judge motion by reading it. transition: transform 400ms cubic-bezier(0.68, -0.55, 0.27, 1.55) describes a specific bouncing ease, but the only way to know whether that bounce feels right for your button is to watch it happen. And watching it happen in your own project means writing the rule, setting up the hover state, saving, and moving your mouse over the element, then adjusting one number and doing it all again. That loop is slow enough that most people settle for the first thing that works rather than the thing that feels best.
A generator turns that loop into a single click. You set a duration and press the trigger, and the preview element plays the transition in front of you. Change the timing function and press it again, and you feel the difference between a linear slide and an ease-out settle immediately. After a few rounds you develop a sense for what two hundred milliseconds feels like versus five hundred, which is the intuition that separates motion that helps from motion that gets in the way. When you are satisfied, the working CSS is already written, so there is nothing to transcribe.
The same reliability argument applies here as with any visual CSS builder: you cannot produce a malformed transition value by dragging sliders and choosing from menus, so the output is always safe to paste. That is the reason I keep this kind of tool close, the same instinct behind reaching for the CSS transform generator when I need a transform rather than counting degrees in my head.
Where does the transition go, on the base state or the hover state?
This is the mistake I see most, and it is worth stating plainly because the fix is so simple. The transition belongs on the element's base state, not on its :hover rule. When the transition is declared on the base state, the browser animates the property in both directions: it eases into the hover change when the pointer arrives, and it eases back out when the pointer leaves. That symmetry is what makes an interaction feel complete.
Put the transition only on :hover and you get a lopsided effect. The property animates smoothly on the way in, because the transition is present while the element is hovered, but the moment the pointer leaves, the :hover rule no longer applies, the transition goes with it, and the property snaps back instantly. The result is a button that eases up gracefully and then jerks back down, which looks worse than no animation at all. The generator's output is written to go on the base state, and the guidance is baked into the tool for exactly this reason. Declare it once, on the element itself, and let the state changes trigger it.
What is the correct order of the transition shorthand?
The transition shorthand packs up to four values into one line, and the order is fixed by the specification: property, duration, timing-function, delay. So transition: opacity 300ms ease-in-out 100ms means the opacity property, animated over three hundred milliseconds, using an ease-in-out curve, after a hundred-millisecond delay. Get the order wrong and the browser either ignores the declaration or reads it as something you did not intend.
The one rule that catches people is the two time values. Both the duration and the delay are times, and CSS distinguishes them purely by position: the first time value is always the duration, and the second is always the delay. If you write only one time value, it is read as the duration, and the delay stays at its default of zero. This is why a transition that seems to start too early is often a case of a delay accidentally written first. The generator sidesteps the whole problem by building the shorthand for you in the correct order, and it omits the delay entirely when it is zero, so you never ship a trailing 0ms that does nothing. Here is the anatomy in a table.
| Part | Example | What it controls |
|---|---|---|
| property | opacity |
Which property animates, or all for every animatable one |
| duration | 300ms |
How long the animation takes; the first time value |
| timing-function | ease-in-out |
The acceleration curve of the motion |
| delay | 100ms |
How long to wait before starting; the second time value |
Why will my display: none transition not animate?
This is the cliff, and almost everyone walks off it at least once. You want an element to fade in, so you transition display from none to block and set opacity, and the element just appears with no fade. The reason is fundamental: display is not an animatable property. There is no halfway point between none and block, no value the browser can interpolate to at the fifty-percent mark, so there is nothing to tween. The change happens instantly, and any opacity animation you layered on top gets cut off because the element was not rendered to begin with.
The classic fix is to animate opacity and visibility together and leave display out of it. visibility can transition because, while it is also a discrete property, pairing it with a duration lets the browser hold the element visible until the opacity fade completes on the way out. The modern fix is transition-behavior: allow-discrete, a newer capability that lets you animate discrete properties like display at the endpoints of a transition, so you genuinely can fade in from display: none in browsers that support it. Either way, the lesson is the same: check that the property you are transitioning has intermediate values before you spend an hour wondering why nothing moves. This is the kind of gotcha that a live preview surfaces in seconds, which is a large part of the argument for building motion where you can watch it.
What is a timing function, and why does it matter so much?
The timing function is the part of a transition that decides how the motion feels, and it does far more work than the duration. Two transitions of the same length can feel completely different depending on their curve. A linear transition moves at a constant speed and feels mechanical, like a machine part. An ease-out transition starts fast and slows as it arrives, which feels natural because it mimics how physical objects decelerate, and it is the right default for most interface motion. ease-in does the opposite and is best for things leaving the screen.
Underneath, all of these are cubic-bezier curves. The keywords ease, ease-in, ease-out and ease-in-out are just friendly names for specific cubic-bezier(x1, y1, x2, y2) values, where the two control points shape the acceleration. What makes cubic-bezier powerful is that a control point with a y value above one or below zero pushes the animation past its endpoint and back, which is how you build an overshoot or a bounce. The generator includes a Material standard curve for clean interface motion and a Back curve that overshoots for a springy, playful feel, plus a steps() function for motion that jumps in discrete frames rather than gliding, which is how you animate a sprite or a ticking counter. Choosing a curve and pressing the trigger is the fastest way to build a feel for what each one does.
When should I use multiple transition layers?
A single transition animates one property, but real interactions often change several at once. A button that lifts on hover might shift its background colour, nudge its transform, and deepen its shadow, and each of those may want its own timing. The transition property handles this with a comma-separated list, where each entry is a full transition with its own property, duration, timing function and delay.
The generator supports this directly: add a layer for each property, tune each independently, and the tool joins them into one shorthand like transition: background-color 200ms ease, transform 200ms ease-out. The reason to give properties separate transitions rather than using all is control and performance. transition: all is convenient, but it animates every property that changes, including ones you did not intend, and it forces the browser to watch everything for changes. Naming the specific properties is both more predictable and cheaper. The Slow reveal preset in the tool shows a two-layer transition, fading opacity and moving a transform together with a shared delay, which is the standard recipe for an element that eases into view. If the transform side of that pairing is what you are tuning, the CSS transform generator is the companion tool, and the two are almost always used together.
Which properties should I animate for smooth performance?
Not all properties are equally cheap to animate, and the choice has a direct effect on whether your transition runs at a smooth sixty frames a second or stutters. The two properties to prefer are transform and opacity. Both can be handed to the GPU and composited without recalculating the page layout, so animating them stays smooth even on modest hardware. This is why a card that slides in with transform: translateX feels buttery while the same card animated with left feels rough.
The properties to avoid animating are the ones that trigger layout: width, height, top, left, margin and padding. Changing any of these forces the browser to recompute the position and size of the element and everything affected by it, on every single frame of the animation, which is expensive and is the most common cause of janky motion. If you find yourself wanting to animate a width, it is usually worth asking whether a transform: scaleX would produce a similar effect more cheaply. The generator lets you pick any property so you are never blocked, but the properties it lists put transform and opacity near the top because those are the ones you should reach for first. The broader case for building a considered set of tools like this is in the web developer toolkit piece, and the workflow habits behind it are in the developer productivity tools guide.
How does the generator keep the preview honest?
Every visual builder faces the same risk: the preview and the exported code drifting apart until the tool teaches you a value that will not reproduce. This generator applies the exact transition value it outputs to the preview element and triggers it with a real state change, so the motion you see is the motion the copied CSS will produce. There is no separate animation path that could disagree.
Because a transition only runs when a property changes, the preview needs a state to toggle between, which is what the trigger button does: it flips the element between two sets of values so the transition fires and you can watch it. This mirrors how a transition works in the wild, where a hover, a focus or a toggled class is what sets it off. The output stays minimal too, dropping the delay when it is zero and listing only the layers you added, the same discipline of emitting only meaningful declarations that runs through the gradient generator and the box-shadow generator.
What browsers support CSS transitions?
CSS transitions are supported in every current browser and have been for well over a decade. The transition property and all its longhands are universal and unprefixed, so the output of this generator works in Chrome, Firefox, Safari and Edge without any vendor prefixes or fallbacks. The newer transition-behavior: allow-discrete capability for animating discrete properties like display is more recent and has narrower support, so treat that specific technique as a progressive enhancement and keep the opacity-and-visibility pairing as your fallback. For the authoritative rules, the CSS Transitions Module Level 1 specification from the W3C is the primary source, and it is worth reading once the generator has given you a feel for how the pieces fit.
If you are assembling a wider set of visual CSS tools, the transform generator and the CSS filter generator pair naturally with this one, since a transition is what smooths the transforms and filters you build with them. Everything here runs client-side, and the CSS you copy is yours to use with no runtime, no build step and no dependency.
Frequently asked questions
What is a CSS transition generator?
A CSS transition generator is a visual tool that builds a CSS transition from settings you choose. You pick a property, duration, timing function and delay, and it outputs the transition shorthand with a live preview you can trigger to watch the easing.
Where do I put the transition, on the base state or the hover state?
Put it on the base state. A transition declared on the base rule animates the property in both directions, into the hover change and back out of it. Declaring it only on hover animates the change in but lets it snap back instantly when the pointer leaves.
What is the order of the transition shorthand?
The order is property, duration, timing-function, delay, for example transition: opacity 300ms ease-in-out 100ms. The first time value is always the duration and the second is always the delay, so a single time value is read as the duration.
Why will my display: none to display: block transition not animate?
Because display is not an animatable property. There is no intermediate value between none and block, so the browser has nothing to tween. Transition opacity and visibility together instead, or use transition-behavior: allow-discrete in newer browsers to fade in from display: none.
Can I transition more than one property at once?
Yes. Separate each transition with a comma, for example transition: opacity 300ms ease, transform 200ms ease-out. This generator builds that list for you as you add layers, giving each property its own duration, timing function and delay.
What is a cubic-bezier timing function?
A cubic-bezier timing function defines a custom acceleration curve from two control points, written cubic-bezier(x1, y1, x2, y2). The keywords ease, ease-in, ease-out and ease-in-out are shortcuts for specific curves, and control points above 1 or below 0 create an overshoot, which is how a bounce is built.
Which properties should I animate for smooth performance?
Prefer transform and opacity. They are composited on the GPU and do not trigger layout, so they animate at 60fps. Animating width, height, top, left or margin forces the browser to recalculate layout on every frame, which is the most common cause of stuttering transitions.
Is the generated transition CSS free and safe to use?
Yes. The tool is completely free with no signup or usage limits, and it emits standard, unprefixed CSS supported in every modern browser. All processing happens in your browser, so nothing is uploaded and the tool works offline once loaded.
