You set the transition. You hovered over the element. It snapped straight to the end state with no motion at all, like the line you wrote isn’t even on the page. Or the entrance animation that played fine in the builder preview is dead on the live site, the section just sitting there, fully visible, refusing to slide in. You’ve already done the obvious things. You checked the spelling, added the -webkit- prefix, bumped the duration up to something you couldn’t miss, refreshed, cleared the cache, refreshed again. Nothing moved.
If you searched css transition not working and landed here, you’re not trying to learn how transitions work. You know how they work. You wrote one that should work, and something is stopping it, and you can’t see what.
CSS transition not working: start with what you can’t see
Most of the answers you’ll find for this assume the problem is a typo in the rule you wrote, and they walk you through the same checklist every time. Is the transition on the base element instead of the :hover state. Are you trying to animate a property that can’t be animated, like height set to auto, or display. Is the syntax right, are the prefixes there, does the browser support it. All of that is real, and on a clean test page it’s usually the answer.
Your site is not a clean test page.
The checklist assumes the only thing touching that element is the line you wrote. On a live site there’s a theme with its own ideas, a page builder that writes styles directly onto elements after the page loads, a handful of plugins, and a rule you added months ago and forgot about. The transition you wrote can be perfect and still lose to a stronger rule sitting on top of it, one that pins the property to a single fixed value so there’s nothing left to move between. No two states, no motion. The element just snaps. That isn’t a typo. That’s a competition you can’t see the scoreboard for.
Here’s the part the checklists leave out, and it’s the part that matters most. When a transition or an animation won’t fire on a real site, the cause is almost never in the CSS you wrote. It’s in something else acting on the same element: a rule you didn’t write, a parent that’s hidden, a setting you didn’t know was on. You can reread your own code for an hour and find nothing wrong with it, because there’s nothing wrong with it.
Why your CSS animation isn’t playing
A keyframe animation fails the same way, for the same reasons, with one extra trapdoor. css animation not working usually comes down to one of three things. The animation is declared, but a stronger rule is winning and holding the property still. The element you’re animating, or a parent above it, is set to display: none, so the browser treats it as if it was never there and the animation has nothing to play on. Or the animation is set to run, but something switched it off before it could start.
That last one is where most people lose hours, because the thing that switched it off isn’t on the element at all.
There’s a developer who wrote about pulling his hair out over exactly this. Same machine, two operating systems. The animations ran on one and were completely dead on the other. He read his code, tested browsers, swapped things in and out, and got nowhere, because the cause wasn’t on the page. Months earlier he’d turned off animations at the operating-system level and forgotten he’d done it. The page was quietly respecting that setting and refusing to animate anything, and no amount of staring at the CSS was ever going to show him a switch that lived on his own computer.
When a plugin or page builder is the one stopping it
Can a WordPress plugin break CSS animations? Yes, and it happens constantly, usually without touching your CSS file at all. A plugin can load its own styles that win over yours. It can wrap your element in extra markup so your rule is no longer pointing at what you think it’s pointing at. It can update itself overnight and ship a change that quietly turns your effects off. People open support threads for this with the same line over and over: I didn’t change anything, and it stopped working. They’re telling the truth. They didn’t change anything. The plugin did.
Elementor is the sharpest current example. If you’re seeing css animation not working in Elementor, or in WordPress generally, check this before anything else. As of Elementor 3.32 and 3.33, Elementor automatically disables entrance animations, motion effects, and transitions whenever the visitor’s device has Reduce Motion turned on. That’s an accessibility setting that lives in the operating system, not in your site. The reports that surfaced this winter were specifically about 3D transforms, the flip and rotate effects, so if you’ve got css transform not working in this exact pattern, the same thing applies. The tell is consistent and worth memorizing: the effect works on mobile and is dead on desktop, or it works on a colleague’s machine and not yours, or the exact same HTML and CSS runs fine outside WordPress entirely. If that’s what you’re seeing, your CSS was never the problem.
How do you fix a CSS animation that stopped working in Elementor when that’s the cause. On the device where the animation is dead, open your accessibility settings and check whether Reduce Motion (called “show animations” on some systems) is switched on. Turn it off, reload the page, and watch. If the animation comes back, you’ve found it, and now you can decide how you want the site to behave for the real visitors who keep that setting on, rather than fighting your own CSS over something that was never broken.
One more cause worth ruling out, because it sits on the line between a visual problem and a functional one. A lot of entrance animations on WordPress aren’t pure CSS, they’re driven by a script. When that script throws an error, every animation it controls can die at once, sliders and carousels included. That’s not a CSS problem, it’s a broken script, and it’s a different kind of hunt. If all your animations failed together right after an update, that’s the likely shape of it, and the trail starts with the server logs rather than the styles. There’s a walkthrough on the Loupely side for turning on the WordPress debug log and reading what it tells you, at useloupely.com (that’s the functional side of the house, separate from the visual diagnosis here).
How to find the blocker, fastest first
So how do you actually find which one of these it is, without reading every line of CSS on the site and checking three operating-system settings by hand. The honest answer for a website owner who can’t see what their site is actually doing is that the standard tools won’t make it easy. DevTools will show you the rules on the element, with the losing ones crossed out, and then leave you to work out which one is holding your property still and where it came from. That last step is the whole problem, and it’s the one DevTools hands back to you.
This is the gap Loupely Lens was built for: you click the element that should be moving, and it reads the full CSS picture behind it, then tells you in real human terms whether your transition is being beaten by a stronger rule, switched off by a setting, or aimed at an element that’s hidden, and exactly where that’s coming from.
If you’d rather work it by hand, the order that saves the most time goes shortest first. Rule out the setting before anything else: check Reduce Motion on the device where it’s failing, because it’s the fastest to confirm and the easiest to miss. Then check whether the element, or anything above it, is set to display: none, since a hidden element can’t animate and the hidden one is usually a parent, not the element you’re staring at. The reason it’s almost always a parent is the same reason elements end up overlapping when you didn’t put them there: the thing in control is a few levels up. It’s the same trap behind a position sticky that won’t stick, where the element is fine and something in its ancestry isn’t.
Last, look at whether a stronger rule is pinning your property to a fixed value, which is the case where your transition is flawless and still has nothing to move between. Finding the winner here is the same hunt as a CSS override not working, and if you’re on Elementor and your styles in general aren’t taking, not just the animation, that’s its own pattern, covered in why Elementor CSS isn’t applying.
The thing to hold onto is simple. When a transition or animation won’t fire on a real site, stop rereading your own code, because the cause is almost always something else acting on the same element: a stronger rule that’s winning, a hidden parent, or a setting you didn’t know was on.
So before you touch the CSS again, go to the device where it’s failing and check whether Reduce Motion is turned on. It takes 10 seconds, it’s the cause people miss most often, and if that’s the one, your hover effect comes back the moment you reload, snapping straight into the motion you wrote in the first place.