A header background color sounds like a five-minute tweak, and on a lot of themes it genuinely is. The part that trips people up isn’t picking a color, it’s figuring out why the “obvious” method doesn’t work on their specific theme, or why the color changes but only partway, leaving a strip of the old shade behind a logo or a sticky nav bar. This covers the full range of approaches, from a two-click Customizer setting through to hunting down the right CSS selector with dev tools, and it also covers the newer Full Site Editing route that a lot of older tutorials on this topic don’t mention at all.
Figure Out What Kind of Theme You’re Running First
This matters more than anything else on this list. WordPress themes now fall into two structurally different categories, and the method that works for one often does nothing on the other.
Classic themes (most themes still in wide use, including BuddyX and most premium themes from Envato or ThemeForest) use the Customizer at Appearance > Customize, PHP templates, and a traditional style.css file. Block themes (“Full Site Editing” or FSE themes, anything built around theme.json, Twenty Twenty-Four and its successors being the obvious examples) replace the Customizer with the Site Editor at Appearance > Editor, and header styling lives inside a header template part rather than a Customizer panel. If you go looking for Appearance > Customize and it’s not there, or it opens but has almost no options in it, you’re very likely on a block theme, and the rest of this needs adjusting accordingly.
Method 1: The Theme Customizer (Classic Themes)
Go to Appearance > Customize, then look for a section labeled Header, Colors, or sometimes buried inside a broader “Site Identity” or “Layout” panel depending on how the theme author organized things. Not every theme exposes header background color as a dedicated control, some only let you set a global accent color that the header inherits, others separate header background from the rest of the site entirely. If you see a color swatch or hex input specifically labeled for the header, select your color and check the live preview panel before publishing, most Customizer implementations render changes in real time so you can catch anything that looks off (text disappearing against a similar-toned background, for instance) before it goes live.
One thing worth checking here: some themes apply the header color change immediately across desktop and mobile, others have a separate “mobile header” toggle or color option that needs setting independently. If your header looks right on desktop and wrong on a phone after this step, that’s usually why, go back into the Customizer and check for a device-specific header setting rather than assuming something’s broken.
Method 2: Custom CSS (When the Customizer Doesn’t Have the Option)
If there’s no built-in header color control, Additional CSS is the next step, and it’s still inside the Customizer at Appearance > Customize > Additional CSS, so you don’t need a plugin just for this. The example most tutorials give is:
header.site-header {
background-color: #yourcolorcode;
}The problem is that header.site-header is a guess, it happens to be the selector on a specific set of themes, and it will simply do nothing if your theme names its header element differently. Rather than guessing, right-click directly on your site’s header in the browser and choose Inspect (Chrome, Firefox, and Edge all support this). The dev tools panel that opens shows you the exact HTML element and class names WordPress is actually rendering, look for something like <header id="masthead" class="site-header"> or <div class="header-wrap">, whatever your specific theme uses. Click through the nested elements in the Elements panel if the outermost header tag doesn’t seem to control the visible background, sometimes the color lives on an inner wrapper div instead, and you can preview the change live in dev tools by editing the CSS right there before committing to it in the Customizer.
Once you have the real selector, the CSS itself is simple:
#masthead {
background-color: #2c3e50 !important;
}Reach for !important only if a more specific, already-existing style is overriding your rule and you’ve confirmed that through dev tools, not as a default habit. Overusing !important across a stylesheet makes future debugging genuinely painful, since it breaks CSS’s normal cascade and specificity rules, and six months from now neither you nor whoever inherits the site will be able to tell which rule is supposed to win.
Method 3: A Child Theme, Not the Live Theme Editor
The original version of this advice pointed people at Appearance > Theme Editor to edit style.css directly. That’s worth actively steering away from for two reasons. First, editing the parent theme’s files directly means every one of those edits gets wiped the next time the theme updates, which for a security or bug-fix update is not optional to skip. Second, a syntax error typed directly into the live theme editor can produce a white screen on your production site immediately, with no undo button in the admin (since the admin itself may now be broken).
If you want your CSS to live in an actual file rather than the Customizer’s Additional CSS box, set up a child theme first, a bare-minimum one only needs a style.css with the correct theme header comment and a functions.php that enqueues the parent stylesheet. Your header color CSS goes in the child theme’s style.css, survives parent theme updates, and if something goes wrong you can fix it by editing the file over FTP or your host’s file manager rather than being locked out of a broken admin panel. For anyone who’d rather not manage a child theme just for a color change, a lightweight snippets plugin like WPCode (formerly Insert Headers and Footers) lets you add scoped CSS without touching theme files at all, and it survives theme switches too.
Method 4: Full Site Editing (Block Themes)
On a block theme, header background color is set inside the Site Editor rather than the Customizer. Go to Appearance > Editor > Templates, find the header template part (it’s usually listed separately under Template Parts as well, since headers are reused across every template), click into it, select the outermost group block that wraps the header content, and open the block settings panel on the right. Under Styles or Background, you’ll find a color picker tied directly to your theme’s theme.json color palette, plus a custom color option if none of the predefined swatches fit.
This is worth calling out specifically because a background color set this way is stored differently than Customizer or Additional CSS changes, it becomes part of the template part itself, tracked in the site’s editor history, and it plays correctly with the theme’s defined color palette rather than being an external override sitting on top of it. If you’re on a block theme and you go looking for Additional CSS-style header controls the way older guides describe, you’ll spend a while confused before realizing the Site Editor is where this now lives entirely.
Page Builders Handle This Separately Again
If your site runs Elementor, Divi, or Beaver Builder with a builder-controlled header (rather than the theme’s native header), none of the above will touch it, because the builder renders its own header template outside the normal theme hierarchy. Elementor’s header widget or Theme Builder header template has its own background color setting directly in the widget’s Style tab. Divi’s Theme Builder works the same way, select the header section, open its background settings in the right-hand panel. If you’ve built a custom header in a page builder and also have leftover Additional CSS targeting the theme’s default header selector, that CSS is likely doing nothing, the builder’s own header markup replaced it, and you’ll want to edit the color inside the builder directly instead.
Advanced: Editing theme.json Directly
For anyone building a child theme on top of a block theme, or maintaining a custom block theme from scratch, header background color can also be set at the source, inside theme.json, rather than through the Site Editor’s UI at all. A minimal example inside the styles object, scoped to the header template part, looks roughly like this:
{
"templateParts": {
"header": {
"color": {
"background": "var(--wp--preset--color--primary-dark)"
}
}
}
}Referencing a preset color variable rather than a raw hex value here means the header automatically stays in sync if the site’s color palette changes later, since every reference to primary-dark updates from one place instead of needing to be hunted down individually. This is more setup than most site owners need for a one-off color change, but it’s the right approach if you’re maintaining a theme that other sites or clients will reuse, where consistency across instances matters more than a quick one-time tweak.
Matching the Header to a Logo or Brand Palette
A header color chosen in isolation, without checking it against the actual logo file sitting inside it, is one of the more common mistakes here. Pull the exact hex values out of your logo file first (most image editors, including free tools like GIMP or the color picker built into macOS Preview, will sample a pixel and give you the hex code directly), and either match the header background to one of those values or choose a shade that sits comfortably behind the logo’s existing contrast design. A logo built with a transparent background and dark text or icon detailing will often look correct on a light header and nearly invisible on a dark one, so check the actual logo file, not just how it looked on the theme demo screenshots, before finalizing a color.
Testing Across Browsers and Real Devices
Color rendering is close to identical across modern browsers now that everything is standardized on similar color management, but header behavior around scroll state, transparency, and sticky positioning is not always identical. Safari on iOS in particular has its own quirks around fixed-position elements and viewport height calculations that can make a header background appear to jump or flicker during scroll on a phone even when it renders perfectly on desktop Chrome. If your theme uses a sticky header, test the actual scroll behavior on a real iPhone or Android device, not just a browser dev tools device emulator, before considering the change finished. Emulators are a reasonable first pass but they don’t reproduce every mobile browser rendering quirk.
Contrast Isn’t Optional
Before locking in a header color, run it against your header text and logo for actual contrast, not just a glance. WCAG AA requires a 4.5:1 contrast ratio for normal text against its background (3:1 for large text), and a header with white text on a light background, or a logo that was designed for a white background suddenly sitting on dark navy, fails this constantly. Chrome’s dev tools will flag contrast issues directly in the color picker when you inspect an element, or use a free contrast checker like WebAIM’s before publishing. This isn’t just an accessibility checkbox, low-contrast headers measurably hurt usability for a meaningful share of any real visitor base, not only people using assistive technology.
Things That Commonly Go Wrong
A color change that “didn’t work” is very often a caching problem rather than a CSS problem, if you’re running a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache) or your host caches at the server level, clear that cache after publishing before concluding the change failed. Browser caching can independently make an old version stick around on your own machine even after server-side cache is cleared, a hard refresh (Cmd+Shift+R or Ctrl+Shift+R) rules that out. Sticky or transparent headers are another common snag, some themes render the header transparent by default and only apply a background color once you’ve scrolled past a certain point, so a Customizer or CSS change might genuinely be working correctly at the top of the page while looking unchanged, because a separate “scrolled” state is what you’re actually seeing. And if you’re testing changes on a staging environment, remember the change needs deploying to production separately, plenty of “it didn’t save” reports turn out to be a change that only ever existed on staging.
Specificity conflicts are the other frequent culprit, particularly on sites that have accumulated years of Additional CSS from different past edits. If a newer rule doesn’t seem to be taking effect, check dev tools for a strikethrough on the property, that’s the browser telling you a more specific selector elsewhere is winning. Rather than reaching for !important immediately, increase your own selector’s specificity to match or beat the conflicting rule (adding an ID, or chaining a parent class), which keeps the stylesheet’s cascade logic intact and makes the next person’s edit easier rather than starting an !important arms race that eventually makes every rule in the file impossible to override cleanly.
RTL Sites Need the Same Selector, Different Layout Assumptions
If you’re running a right-to-left site (Arabic, Hebrew, and similar), the background color CSS itself doesn’t change, color isn’t a directional property. What does need checking is whether your theme’s header layout (logo position, nav alignment, any decorative border or gradient edge) was built assuming left-to-right reading order. A gradient header that fades from a solid color on the left to transparent on the right will look backwards on an RTL site unless the theme (or your custom CSS) accounts for direction using logical properties, and it’s worth checking that specifically after any header styling change on a multilingual site using Polylang or WPML with an RTL language active.
Temporary or Seasonal Header Colors
Some sites want a header color that changes for a specific window, a holiday promotion, an event, a limited-time campaign, and then reverts. Hard-coding a new color and remembering to revert it manually is an easy step to forget. If this is a recurring need rather than a one-off, a small snippet through WPCode with a scheduled date check, or simply two saved versions of your Additional CSS kept in a text file ready to swap, beats relying on memory. For anything more elaborate than a background color, an actual seasonal header graphic swap, most site owners are better served by a dedicated events or promotion plugin than by hand-rolling date logic into custom CSS.
Dark Mode Adds One More Layer
If your theme or site supports a dark mode toggle, a single fixed header background color will look wrong in one of the two states no matter which you pick. The more durable fix is to define the header background as a CSS custom property that swaps value based on a prefers-color-scheme media query or a data-theme attribute, rather than a single hard-coded hex value, so it’s set once and adapts automatically instead of needing a manual toggle-specific override maintained separately. It’s a small amount of extra setup the first time, and it saves you from re-doing this entire exercise the day someone asks why the header still looks jarring in dark mode.
Whichever method ends up fitting your theme, the underlying goal is the same: change the color in one place that survives updates, confirm it actually reads well against your logo and nav text, and check it on a real phone before calling it done. A header that looks right on your desktop monitor at 1440px wide and wrong on the device most of your visitors are actually using isn’t finished yet.
Interesting Reads:
Should I Remove Polyfill From WordPress