How to Change Background Color of My Site Header in WordPress
The header background color question sounds simple until you actually try to change it and nothing happens, or it changes on desktop but not mobile, or a page builder plugin is quietly overriding whatever you set everywhere else. All of that comes down to one thing most quick-tip articles skip: which kind of WordPress theme you’re actually running determines which method will work, and trying the wrong one is where people waste an afternoon.
Classic theme or block theme: check this first
Go to Appearance in your dashboard. If you see a menu item called Editor that opens a full-page visual editor covering your header, content, and footer as blocks, you’re on a block theme (also called a Full Site Editing or FSE theme), Twenty Twenty-Four and Twenty Twenty-Five are the WordPress-provided defaults, but Kadence, Blocksy, and Neve all ship block-theme variants too. If instead you see Customize, which opens a sidebar panel with live preview, you’re on a classic theme, this covers most of Astra, GeneratePress, OceanWP, and the majority of premium themes still in wide use.
This distinction changes everything downstream. Block themes store their color settings in a theme.json file and expose header styling through the Site Editor’s Styles panel. Classic themes rely on the Customizer, theme-specific settings panels, or raw CSS. Following a classic-theme tutorial on a block theme (or the reverse) is the single most common reason people report that “nothing works.”
Worth setting expectations up front: this isn’t a two-minute job if the goal is a color that actually matches your brand, holds up on mobile, and doesn’t quietly break text readability. It’s a fifteen-minute job done properly, most of which is verification rather than the actual color change itself.
Classic themes: the Customizer
Go to Appearance > Customize. Most classic themes expose a Header section, sometimes nested under Colors or a theme-specific panel. Astra, for example, puts header background under Header Builder > General, while GeneratePress puts it under Colors > Header Background.
If the theme genuinely has no header color control (some minimal themes leave header styling entirely to CSS), the option simply won’t be there, and no amount of clicking around will find it. That’s the signal to move to custom CSS instead of assuming you’re looking in the wrong place.
One thing that trips people up here: some themes distinguish between the site header and a separate “page header” or “hero” area shown above page titles. Changing one doesn’t touch the other, which is why a color change sometimes only affects part of what visually looks like the header.
Block themes: theme.json and the Site Editor
On a block theme, the header is a template part, usually literally called “Header” in the Site Editor’s Templates > Template Parts list. Open it, click on the outer Group or Cover block that wraps the whole header (not an inner element like the logo or navigation), and the block sidebar shows a Background color swatch under Styles.
Changes made this way through the editor get saved as a customization layered over the theme’s defaults, stored in the database rather than in the theme’s files, which means a theme update won’t wipe them out. That’s a meaningful advantage over raw CSS: block theme customizations survive updates by design, not by luck.
For a change meant to apply site-wide and travel with the theme itself (useful if you’re building a child theme or maintaining multiple sites off one base), the equivalent lives in theme.json:
{
"styles": {
"blocks": {
"core/template-part": {
"variations": {
"header": {
"color": {
"background": "#1a1a2e"
}
}
}
}
}
}
}In practice, targeting the header template part specifically inside theme.json is fiddly across different block themes because the exact slot names vary. The more reliable route for most people is setting the color through the Site Editor UI on the header template part directly, which writes the equivalent styling to the database without needing to hand-edit JSON at all.
Custom CSS: the method that works regardless of theme type
When the theme doesn’t expose a header color setting, or you need more precision than a color picker gives you (a gradient, a background image with an overlay, a different color per breakpoint), custom CSS is the fallback that works everywhere. Add it under Appearance > Customize > Additional CSS on a classic theme, or Appearance > Editor > Styles > Additional CSS on a block theme.
The part tutorials usually skip is that .site-header isn’t a universal selector, it’s just a common convention some themes happen to use. The actual class or ID on your header depends entirely on your theme’s markup. Right-click the header in your browser, choose Inspect, and look at the outermost element wrapping the logo and navigation together. Astra typically uses .site-header, GeneratePress uses .site-header as well but with different inner structure, Kadence uses .site-header, and plenty of custom or lesser-known themes use something theme-specific entirely.
.site-header {
background-color: #1a1a2e;
}If that doesn’t change anything, the theme’s own CSS is winning the specificity fight. A more specific selector, or a body class prefix, usually settles it:
body.home .site-header,
body .site-header.site-header {
background-color: #1a1a2e !important;
}!important is the blunt-force option and it works, but it also makes future overrides harder for you or anyone else who touches the CSS later, since the only way to beat an !important rule is another !important rule with equal or higher priority. Reach for a more specific selector first and treat !important as the last resort, not the default.
Different color per breakpoint
A header that reads fine at desktop width sometimes looks cramped or low-contrast once the theme collapses navigation into a mobile menu. Media queries handle this cleanly without touching the Customizer at all:
.site-header {
background-color: #1a1a2e;
}
@media (max-width: 768px) {
.site-header {
background-color: #16161f;
}
}Transparent and sticky headers need a different approach
Themes with a transparent header over a hero image, one that turns solid once the visitor scrolls, usually implement that with JavaScript toggling a class (something like .scrolled or .is-sticky) rather than a static background color. Changing background-color on the base .site-header selector in that case only affects the color after the toggle fires, or does nothing at all if the theme applies its transparent styling with higher specificity than your rule. Check the theme’s documentation or inspect the class list on the header element before and after scrolling to see what’s actually toggling, then target that specific state:
.site-header {
background-color: transparent;
}
.site-header.scrolled {
background-color: #1a1a2e;
}A related snag shows up on WooCommerce or landing-page setups where the header sits over a full-bleed hero image only on the homepage but needs a solid background everywhere else. Rather than fighting one selector to behave two different ways, scope the transparent version to the homepage body class specifically and let every other template fall back to the theme’s normal solid header, which avoids a tangle of conditional overrides fighting each other in the same stylesheet.
.site-header {
background-color: #1a1a2e;
}
body.home .site-header {
background-color: transparent;
}
body.home .site-header.scrolled {
background-color: #1a1a2e;
}Page builder plugins: a separate override layer
If Elementor, Divi, or Beaver Builder is managing your header specifically (not just the page content, the header itself, via a theme builder or template feature), none of the methods above will touch it. The color lives inside the builder’s own header template, editable only from within that plugin’s interface. This is a common source of confusion: someone sets a color in the Customizer, sees no change, and doesn’t realize the theme’s native header isn’t even the one rendering, the page builder has replaced it entirely.
A quick way to check: view page source (not Inspect Element, actual View Page Source) and search for elementor-location-header or et_header or similar builder-specific class names near the top of the markup. If you find one, the builder owns the header and that’s where the color setting needs to change.
Plugins for visual editing without touching code
CSS Hero and YellowPencil both add a point-and-click visual editor layered over your live site: click an element, adjust color, save. They’re genuinely useful when a theme has no built-in header color option and writing CSS by hand isn’t appealing, but they add their own CSS output on top of the theme’s existing styles, which means the same specificity issues from the manual CSS section still apply, the plugin is handling the syntax for you, not sidestepping the underlying CSS cascade.
Comparing the methods
| Method | Best for | Survives theme update? | Needs code? |
|---|---|---|---|
| Customizer / theme settings | Classic themes with a built-in header panel | Yes, stored in the database | No |
| Site Editor (block theme) | Block/FSE themes editing per-site | Yes, stored in the database | No |
| theme.json | Building or maintaining a child theme | Yes, part of the theme files | Yes, JSON |
| Custom CSS | Any theme lacking a color option, or needing gradients/breakpoints | Yes, if placed in Additional CSS or a child theme | Yes, CSS |
| CSS Hero / YellowPencil | Visual editing without writing CSS by hand | Yes, plugin stores its own output | No |
| Page builder header template | Sites where Elementor/Divi/Beaver Builder owns the header | Yes, within that plugin | No |
Matching the header to an existing brand palette
If a logo or brand guide already exists, pulling the exact color rather than eyeballing something close matters more than it seems. Open the logo file in any image editor with an eyedropper tool, or if it’s a vector file, most design tools show the exact hex value in the layer properties directly. Punching a guessed hex code into the Customizer instead of the real one is a common reason a “brand match” header still looks slightly off; a difference of even a few RGB points reads as wrong to anyone who has stared at the actual logo for hours, even if a casual visitor wouldn’t consciously notice.
Once the base color is locked in, generating a small palette around it (a slightly darker shade for hover states, a lighter tint for section backgrounds elsewhere on the page) keeps the header from feeling like an isolated decision. Coolors.co and Adobe Color both generate tint and shade scales from a single hex input in seconds, which is faster and more consistent than manually adjusting brightness sliders until something looks right.
Block themes make this reusable in a way classic themes generally don’t: once a color is added through the Site Editor’s Styles > Colors panel, it becomes a named entry in the site’s color palette, available afterward in every block’s color picker across the whole site, not just the header. That’s worth doing even if the header is the only reason a custom color got added in the first place, since it means the next section that needs the same brand color is a one-click selection rather than another copy-pasted hex code.
Why the change sometimes doesn’t show up at all
Caching is the most common reason a correctly-applied change appears to do nothing. Page caching plugins (WP Rocket, LiteSpeed Cache, W3 Total Cache) and host-level caching (Cloudflare, a CDN, some managed hosts’ built-in cache) can all serve a pre-generated version of the page that predates your CSS change. Clear the plugin’s cache, then separately purge any CDN or host-level cache, then hard-refresh the browser (Ctrl+Shift+R or Cmd+Shift+R) to rule out browser caching too, since all three layers cache independently and clearing only one leaves the old version showing from the others.
If clearing every cache layer still shows no change, go back to specificity: open DevTools, click the header element, and check the Styles panel for your rule. If it’s there but crossed out (strikethrough), something more specific is beating it, and DevTools will show exactly which selector is winning, which is faster than guessing.
A less common but real cause: some themes load a separate stylesheet specifically for logged-in admin previews versus the logged-out public view, meant to show admin notices or a customizer preview bar. If a color change looks correct while you’re logged in and testing but reverts for anonymous visitors, check the page in a private/incognito browser window rather than trusting what you see in your own logged-in session.
One last habit worth building: after any header color change, load the site on an actual phone rather than trusting a browser’s device-emulation view. Emulators are close but not perfect, particularly for how sticky headers and scroll-triggered class toggles behave, and a header that looks correct in Chrome’s mobile simulator has occasionally rendered differently on real iOS Safari due to how that browser handles fixed positioning and viewport units.
Frequently Asked Questions
Why doesn’t my theme have a header color option in the Customizer?
Some minimal or developer-focused themes intentionally leave styling to CSS rather than building out a settings panel. If Appearance > Customize has no Header or Colors section covering the header specifically, custom CSS is the correct fallback, not a workaround.
How do I know if I’m on a block theme or classic theme?
Check Appearance in the dashboard. An “Editor” menu item that opens a full-page block-based interface means block theme (FSE); a “Customize” item that opens a sidebar with live preview means classic theme. Twenty Twenty-Four and Twenty Twenty-Five are block themes by default; most Astra, GeneratePress, and OceanWP installs are classic unless specifically configured otherwise.
My header color change works on desktop but not mobile. Why?
The theme likely applies different styling at mobile breakpoints, often to accommodate a collapsed hamburger menu, and that mobile-specific CSS can override a rule that only targets the base .site-header selector. A media query scoped to the same max-width the theme uses for its own mobile styles usually fixes it.
Does changing header color affect SEO?
Not directly. Search engines don’t factor visual color choices into rankings. The only indirect link is accessibility and readability: a header with poor text contrast can increase bounce rate, which is a behavioral signal that can affect rankings over time, though the color itself carries no direct SEO weight.
Can I set a different header color for just one page?
Yes, using a body class WordPress adds automatically. Every page gets a unique ID-based class like page-id-42, so a rule scoped to body.page-id-42 .site-header applies only there. Block themes offer an easier native path: apply a Group block style override directly on that page’s header if the theme allows per-page template part variations.
I changed the color but it only shows correctly when I’m logged into WordPress. What’s happening?
Check the page in a private or incognito window, since a logged-in admin session sometimes displays a different cached or preview version of a page than what anonymous visitors see. If it’s still wrong in incognito, work through the caching checklist: plugin cache, CDN or host-level cache, then a hard browser refresh, in that order.
How do I find the exact hex code from my logo?
Open the logo file in any image editor with a color picker or eyedropper tool and click directly on the color you want to match; the tool will display the exact hex value. For a vector logo file, the color is usually already listed as a hex value in the layer or object properties, no picking required.
Interesting Reads
