CSS override not working: how to find which rule is winning and where it came from

You added the CSS. You saved it. You refreshed the page. The element looks exactly the same.

I know this feeling specifically. I’ve sat there staring at Chrome DevTools, clicking on elements that look wrong, feeling frustrated and stuck because something that seems like it should be so simple and easy to fix is somehow deeply complicated. I knew a competition was running in the browser. I knew multiple stylesheets were fighting over which one got to decide what an element looked like. What I didn’t know was which stylesheet was winning, which stylesheets those even were, or where they lived. I was changing things I could see, in the hope that one of them would eventually override whatever I couldn’t see.

That’s not a strategy. That’s guessing in the dark.

When you read explanations of this problem online, they tend to go one of two ways: either the fix doesn’t work because it wasn’t written for your specific tech stack, your specific combination of theme and page builder and plugins all competing with each other, or the fix is described as easy and you feel stupid for not getting it right, because it should be easy, but it’s not. A stranger on a forum doesn’t know your setup. They don’t know you’ve got competing stylesheets from a page builder, from plugins, from WordPress itself. Their answer is for a theoretical site. Yours isn’t theoretical.

Here’s what’s actually happening, and how to find the rule that’s winning.

Why CSS overrides fail: what the browser is actually doing

When more than one CSS rule applies to the same element, the browser runs through a priority order to decide which one wins. The rule with the highest priority applies. Everything else is ignored for that property.

The priority order, from highest to lowest: inline styles (written directly on the element in the HTML) beat everything, then specificity (how precisely the selector targets the element), then source order (which rule appears later in the stylesheet). !important overrides all of that except another !important with higher specificity. And where rules came from matters too: your theme, your page builder, a plugin, a JavaScript injection, and the browser’s own defaults all sit at different layers.

When your override fails, one of these is true: the rule you added has lower specificity than the rule it’s trying to beat. A rule from a different source is loading after yours and overriding it. The rule you added is targeting the wrong selector entirely. Or something higher up in the DOM is constraining the element, and the problem isn’t on the element you’re looking at at all.

You can’t diagnose any of this from your page builder or your Custom CSS panel. You need to see what the browser is seeing.

CSS override not working: how to diagnose it in the browser

Open the page where the element looks wrong. Right-click directly on it and choose Inspect. The DevTools panel will open with the element selected in the Elements panel.

On the right side, find the Styles tab. The rule at the top of the list is what’s being applied. Rules below it that target the same property are crossed out. Those are the ones that lost. Look at the crossed-out rules: that’s where your override probably is.

Now look at where each rule came from. Under each rule in the Styles tab, you’ll see a filename and a line number, something like theme.css:2847 or elementor-pro.min.css:1 or style.css. That tells you the origin: the theme, the page builder, a plugin, or your own stylesheet.

The rule that’s winning: check its origin. If it’s coming from your theme at higher specificity than what you wrote, that’s the conflict. If it’s an inline style (it will show as element.style in the panel), something is applying styles directly onto the element in the HTML, which means your stylesheet can’t beat it without matching that specificity.

The Computed tab: see what actually applied

The Styles tab shows you every rule the browser considered. The Computed tab shows you the final result: what the browser decided to apply after running through all of them.

Click Computed in the DevTools panel. Find the property that isn’t changing, say background-color or color. Click the arrow next to it. The browser will show you the exact rule that won and the file it came from. This is often faster than reading through the Styles tab when you have many competing rules.

If you’d rather not navigate this manually, especially when you’ve got Elementor’s generated classes stacked on top of plugin classes stacked on top of a theme stylesheet, Loupely Lens reads the full CSS cascade of any element you click — every rule that applied, every rule that lost, where each one came from, and the full ancestor chain above it — and tells you in real human terms which rule is winning and why.

The most common reason your CSS override isn’t working

Specificity is the cause most of the time. A selector like .my-button has lower specificity than #main-content .widget .my-button. If the theme or page builder uses a long, chained selector to style an element and you’re overriding it with a short class selector, your rule loses even if it appears later in the stylesheet.

To beat a high-specificity rule, you need a selector of equal or higher specificity. DevTools shows you the winning selector in the Styles tab. Copy it. Add it to your Custom CSS panel with the property you want to change. That selector has the same specificity as the original, and if your stylesheet loads later, yours will win on source order.

If that still doesn’t work, check whether the rule you’re trying to override has !important on it. In the Styles tab, !important declarations appear with an icon next to them. A rule with !important beats rules without it, regardless of specificity. To override it, you need your own !important on a rule of equal or higher specificity. Worth verifying before assuming your selector is wrong.

When the problem isn’t on the element you’re looking at

One of the more disorienting versions of this: you’ve found the winning rule, it looks correct, and the element still isn’t displaying the way you expect. The constraint isn’t on the element itself. It’s on a parent.

A section refusing to center is often not a centering problem on the section. It’s a fixed width, an overflow setting, or a flex configuration on a container two levels above it. The element is doing exactly what its CSS says. Something higher in the DOM is limiting what that CSS can produce.

In DevTools, click on the parent element and check its Styles tab the same way. Then the grandparent. The ancestor chain shows you what’s actually constraining the layout. The problem is almost never where you first look. This is especially true when you’re working in a page builder that adds wrapper divs between you and the element, each one potentially carrying its own rules.

Where your override goes when it’s loading but still losing

If your Custom CSS is loading, DevTools can confirm it. Your rules will appear in the Styles tab with a filename matching your stylesheet. If they’re crossed out, they’re losing to something with higher specificity. If they don’t appear at all, the stylesheet isn’t loading correctly, or the selector isn’t matching the element.

In WordPress, custom CSS added through the Customizer appears as customizer-custom-css in DevTools. Custom CSS added through Elementor appears differently depending on whether it’s element-level or global. A rule that looks right in your editor may not be targeting the rendered element if the page builder added wrapper classes or IDs that change the selector context.

If your rule isn’t appearing in the Styles tab at all, check the selector against the element’s actual classes and IDs in the Elements panel. The selector you wrote and the selector the browser needs to match may not be the same thing, even if they look similar.

The diagnostic sequence

When your CSS override isn’t working, run through this in order:

1. Open DevTools and click the element.
2. Find the winning rule in the Styles tab and note where it came from.
3. Check whether your override appears in the list and whether it’s crossed out.
4. If it is crossed out, compare the specificity of the winning selector to yours.
5. If the winning rule has !important, check whether yours does too.
6. If your rule doesn’t appear at all, verify the selector is matching the actual rendered element.
7. If all of that looks correct and the element is still wrong, click up to the parent element and check its Styles tab, then the grandparent. The constraint is somewhere in that chain.

The browser has a complete and accurate picture of exactly why the element looks the way it does. You’re not missing something everyone else understands. You’re missing a way to see what the browser already knows. Open DevTools, right-click the element, choose Inspect, and start with the Styles tab. The crossed-out rule near the top of the list is almost always where your override went.