CSS button wrong color: how to find which rule is winning
I am dealing with this right now. The button on my site keeps reverting to my theme’s default color no matter what I do. I tried custom CSS. I tried a child theme. I styled the button directly on the page with CSS and HTML. The button ignored all of it. Every new button I added anywhere on the site showed up in that same color: that generic SaaS electric blue. I remember thinking, I never want to see a blue button again. It sat there mocking me every damn time I looked at it.
The thing is, I knew a competition was running in the browser. I knew multiple stylesheets were fighting over which one got to decide what that button looked like. What I didn’t know was which stylesheet was winning, what those stylesheets 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.
I’m switching away from Elementor to the Kadence theme now, specifically so I can build from pure HTML and CSS with no page builder between me and the output. But the problem I’m describing here isn’t specific to Elementor. It’s how CSS works on every platform, and understanding it is the only thing that makes the fix reliable instead of accidental.
Why the setting you changed didn’t work
When a browser renders a button, it doesn’t just look at the one rule you set. It collects every CSS rule from every source that has an opinion about that button: your theme’s stylesheet, your page builder’s output, any plugins that inject styles, inline styles applied by JavaScript, and the browser’s own defaults. Then it runs a calculation to decide which rule wins for each property. The color you see on the page is the winner of that calculation, not necessarily the value you set most recently.
The calculation is based on specificity and source order. A rule with a more specific selector beats a less specific one, regardless of which came first. An inline style beats almost everything. A rule marked !important beats inline styles. When two rules have identical specificity, the one that loads later wins.
Your theme may have a rule like button.wp-element-button { background-color: #2c2c2c; } that is more specific than the class you set in your page builder. The editor preview shows the right color because it applies styles inline during editing. The moment the page renders in a real browser, the theme’s stylesheet loads and its more specific selector takes over. The editor lied to you. The browser is telling the truth.
This is why the child theme didn’t work either, in my case and probably in yours. A child theme inherits from the parent and lets you override styles, but if the parent theme’s rule has higher specificity than what you wrote in the child theme, the parent wins anyway. The child theme approach is sound in principle. It just doesn’t solve a specificity conflict on its own.
Most explanations of this problem either don’t address your specific tech stack, so the fix works for them but not for you, or they describe it as an easy fix and you feel stupid for not getting it right. It’s not easy. It looks easy from the outside because the fix, once you know exactly which rule is winning, is usually one line. The investigation is what takes hours. Nobody explains the investigation.
What the browser already knows
Here’s the part that took me a long time to absorb: the browser has a complete, accurate picture of exactly why your button is the wrong color. It generated that picture when it loaded the page. The winning rule, every competing rule, where each came from, and what specificity score each carried are all sitting in the computed styles panel, waiting to be read.
The problem isn’t the information. It’s the interface. DevTools was built for developers who can look at a specificity score and immediately know whether to change the selector, the value, or the source file. If you open the inspector and see a panel full of crossed-out declarations and competing selectors, you’re looking at the answer. You just have no way to use it.
That’s not a skills gap. It’s a translation gap.
CSS button wrong color: how to find which rule is winning
Right-click your button in Chrome and select Inspect. In the Elements panel, find the Styles tab on the right. You’ll see a list of CSS rules applying to the button. Rules with a strikethrough were overridden by something with higher specificity or that loaded later. The rule at the top of the list, on the property you care about, without a strikethrough, is the winner.
What you’re looking for is the source of that winning rule. To the right of each rule you’ll see a filename and line number. That filename tells you whether the rule came from your theme, your page builder, a plugin stylesheet, or an inline style. If the winning rule came from your theme’s style.css and you’ve been editing your page builder’s color field, you’ve been editing the wrong place the whole time.
The limitation: you have to know what to look for, and you’re only seeing the rules that directly apply to the element you clicked. If the constraint is coming from a parent element above it, or a JavaScript-injected inline style that fires after the page loads, DevTools will show you all of it but won’t organize it into a diagnosis.
If reading the Styles panel feels like exactly the kind of thing that should be simple but isn’t, Loupely Lens handles the translation. Click on the button that’s the wrong color and Lens reads the complete CSS picture: every rule applying to it, every rule that lost, where each came from (theme, page builder, plugin, inline style, browser default), and the full ancestor chain above it. The popup shows you the diagnosis in real human terms before anything downloads: which rule is winning, where it came from, and what that means for fixing it.
The most common sources of a wrong button color
Once you can see which rule is winning, the fix usually falls into one of these categories.
Your theme is overriding your page builder. The theme’s stylesheet has a more specific selector targeting buttons, and it loads after your page builder’s styles. The page builder preview showed the right color because it applies styles inline during editing. The real page renders differently. The fix is adding a more specific rule in your theme’s Custom CSS panel, or adding a scoped override that specifically targets that button.
A plugin is injecting styles. WooCommerce, contact form plugins, membership plugins, and others inject their own CSS. If one has an opinion about button colors and loads after your theme, it wins. The origin classification in DevTools will show you the filename. If it says something like woocommerce-inline or a plugin slug you recognize, that’s the culprit. Check whether the plugin has its own style settings before writing a custom override.
An inline style is applied by JavaScript. Some page builders and theme frameworks apply styles directly to elements after the page loads. These inline styles have very high specificity and are invisible in the page builder editor. A style="" attribute on the button element itself in the inspector is the tell. A regular CSS override won’t beat it without !important.
A parent element is applying the color. Some themes apply color rules to containers that cascade down to buttons inside them. If the winning rule isn’t on the button itself but on a wrapper element two levels up, changing the button directly won’t help. This is where the ancestor chain matters.
What to do once you know the source
If the winning rule came from your theme’s stylesheet, add a more specific rule in your theme’s Custom CSS panel (Appearance, then Customize, then Additional CSS). Target the button specifically enough that your rule wins the specificity calculation. If you’re using a block theme with Global Styles, check whether there’s a button color setting there that overrides your page-level customizations.
If the winning rule came from a plugin, check the plugin’s own settings first. WooCommerce has button color fields in the Customizer. Overriding at the CSS level when there’s a UI setting is extra work you don’t need.
If you tried !important and it still didn’t work, something else also has !important and is loading later. That’s a different fight entirely, and the post on CSS overrides not working covers how to find which rule is beating yours even after you’ve added it.
If you’re using Elementor and button styles aren’t applying at all on the live site, Elementor CSS not applying covers the generated CSS regeneration issue that trips up most Elementor users adding custom overrides.
The investigation is what takes the time, not the fix. Once you know exactly which rule is winning and where it came from, the fix is usually one line pasted in the right place. To find the winning rule: right-click your button, choose Inspect, open the Styles tab, and look at the rule at the top of the list on background-color without a strikethrough. The filename next to it tells you where to apply your fix.
