Shopify button wrong color after changing theme settings: what’s overriding it
You went into your Shopify theme settings and changed the button color. You saved. You refreshed the storefront. The button is still the old color.
So you went back in and changed it again, to something obviously different this time, just to know for certain whether it worked. You saved again. Still the old color.
The setting is doing something. It’s just not doing anything to that button. Something else is controlling the color, and it has more authority over that element than your theme settings do. That’s the whole problem, and it’s maddening specifically because it seems like it should be such a small fix. You changed the setting. Why didn’t the button change?
Here’s what’s actually happening, and how to find the thing that’s winning.
Why theme settings don’t always control button color
Shopify theme settings work by writing CSS variable values that the theme’s stylesheet references. When you set a button color in the theme editor, Shopify updates a variable like --color-button and the stylesheet applies it to button elements across the store. This works correctly as long as every button on your store is actually using that variable.
The problem is that a lot of things on a Shopify store add their own button styles that don’t use the theme’s variables at all. Third-party apps frequently inject their own stylesheets with hardcoded color values. An app button, a review widget, a cart drawer, an upsell popup: these elements often have background-color set to a specific hex value, written directly in the app’s own CSS, with no connection to your theme’s variable. When you change the theme setting, those elements don’t respond. They were never listening.
Theme sections added by apps, or by a previous developer, can have the same problem. The button in that section was styled with a hardcoded value at build time, not a theme variable, and the theme editor has no reach over it.
There’s also a specificity conflict that can affect even theme-native buttons. If an app or a code snippet added a CSS rule that targets buttons with higher specificity than the theme’s rule, that rule wins regardless of what the theme variable is set to. The variable updates, the theme’s rule updates, and the more specific rule sitting above it doesn’t move. This is one of the more infuriating things about CSS: you can make a change that is technically correct, and nothing visible happens, because something else has more authority and you can’t see it without digging.
I’ve hit this pattern on nearly every site I’ve worked on, not on Shopify but on WordPress, where a plugin is calling the shots on how a page displays and Elementor is competing with it from another direction. You stare at DevTools, you select the element that looks wrong, and you feel stuck because something that seems like it should take two minutes is somehow deeply complicated. The platform is different but the feeling is identical.
How to find which rule is controlling the color
Open your storefront in Chrome. Right-click on the button showing the wrong color and select Inspect. In the Styles panel on the right, look at the rules applying to the button. You’re looking for the background-color property. Rules that are crossed out have been overridden. The one that isn’t crossed out is what’s controlling the color you see.
Note where that rule came from. The selector and source file appear next to each rule. A rule from your theme’s main stylesheet is expected. A rule from an app’s stylesheet, from an inline style attribute directly on the element, or from a <style> block injected by JavaScript is the override.
If navigating DevTools feels like reading a foreign language, Loupely Lens reads the full CSS cascade for you. Click on the button with Lens active and it identifies every rule applying to that element, which one is winning, and where it came from: your theme, an app, an inline style, or a JavaScript injection. It tells you this in real human terms, which tells you exactly where to apply the fix. You don’t need to parse specificity hierarchies or know what a crossed-out rule means. Lens reads the cascade and gives you the answer.
Fixing it based on where the rule came from
If the winning rule is from a third-party app stylesheet, check whether the app has its own color settings. Some apps have a button color or brand color option in their configuration panel. If that setting exists and you update it to match your theme, the conflict resolves without any code.
If the app has no color settings, you’ll need to write a CSS override that targets the specific button with higher specificity than the app’s rule. Add this in Online Store, then Themes, then Edit Code, in your theme’s CSS file or a dedicated custom CSS file. Target the button as precisely as you can to avoid affecting other elements.
A word of caution here: writing an override with !important is often the fastest fix, and sometimes it’s the only option if the app’s rule already uses it. But it has a cost. Fix one thing and you may break something else. Then an app update changes the rule you were overriding, and your !important is now fighting a different battle than the one it was written for. This is the thing nobody warns you about: every override you add is a commitment to maintain, and on a store with multiple apps and a history of customizations, those commitments stack up in ways that become genuinely difficult to track. I live with that on my own sites. Every update carries the fear of a ripple effect I can’t see without checking every page individually.
If the winning rule is an inline style (shown as a style attribute directly on the button in the HTML), it was set by JavaScript at runtime. Inline styles beat almost everything in the cascade, so a regular CSS rule won’t override it. You need to find which script is setting it and configure or remove that script, or use !important in your override, which brings the same risks described above.
If the winning rule is from your theme but uses a hardcoded value instead of a CSS variable, the theme has inconsistent styling. Some themes apply the variable to most buttons but not all, particularly in sections added later or built by different developers. Fix it by editing the theme code to replace the hardcoded value with the correct CSS variable, or add a custom CSS rule targeting that specific button.
Rule out caching first
Before you go through any of the above, eliminate caching as the cause. Shopify caches aggressively, and a color change you made might not be visible yet because a cached version of the page or stylesheet is still being served.
Do a hard refresh in Chrome: Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows. Then check the page in a private window, which bypasses browser cache entirely. If the button shows the correct color in an incognito window right after saving, caching was the problem and it will resolve as caches expire.
If the button is still wrong in a fresh incognito window right after saving, caching isn’t the issue. The inspection process above will find the actual cause.
The pattern this follows
Most Shopify button color problems trace back to one of three things: a third-party app that added its own button styles with hardcoded values, a specificity conflict where an app or custom code rule has higher priority than the theme rule, or a theme section built with a hardcoded color instead of a CSS variable. The theme setting isn’t broken. It’s just not connected to the element you’re looking at.
The disconnection takes less than a minute to find once you know where to look. The button’s CSS cascade has the answer. The hard part is reading it, and that’s exactly the part where having a tool that reads it for you changes how long this takes.
If you’re seeing the same kind of problem on a different platform, where a CSS change isn’t applying to the element you expected, the underlying structure is a cascade conflict: something with more authority is winning, and you need to find it before you can fix it. But how you find it, and where the override lives, is specific to the platform you’re on. Shopify’s cascade looks different from WordPress’s, and the fix that works in one context won’t necessarily translate.
