WordPress Additional CSS not working? Six causes, in order

You paste a rule into Appearance → Customize → Additional CSS, the preview shows the change, you press Publish, and the live site looks exactly as it did before. Or the rule worked last month and stopped. WordPress Additional CSS not working is one of the most common front-end complaints, and it almost always has one of six causes.

Check them in this order. Each check takes about 30 seconds, and the first three cover most cases.

Cause 1: a cache is serving the old page

The Customizer preview is built fresh every time, which is why the change shows there. The live page usually comes from a cache: a caching plugin, your host’s page cache, or a CDN such as Cloudflare. Those keep serving the copy they made before you pressed Publish.

The 30-second check. Open the page in a private window with a throwaway query string on the end, such as ?nocache=1. Most caches treat that as a different page and fetch it fresh. If the rule shows up now, the CSS is fine and the cache is the problem. Purge it: the caching plugin’s clear button, your host’s cache panel, and the CDN’s purge, in that order. Some setups have all three, and each has to be cleared.

Cause 2: the theme’s rule wins on specificity

CSS applies the most specific selector, not the last one written. A theme rule like .site-header .site-title a { color: #111 } beats your .site-title a { color: red } no matter where yours is printed, because it names one more class.

The 30-second check. Right-click the element, choose Inspect, and look at the Styles panel. Your rule is there, but struck through, with the theme’s rule above it. That strike-through is the tell. Fix it by matching the theme’s selector and adding one more class or element, so yours is more specific. !important is fine for a one-off override of a theme rule you don’t control; it becomes a problem when every rule has it and nothing can override anything.

If your rule is not in the panel at all, it isn’t reaching the page. Go back to cause 1, or on to cause 4.

Cause 3: the selector targets a class that doesn’t exist

Class names like .site-title and .entry-content are common, not universal. A theme update can rename them, a block theme uses .wp-block-site-title instead, and some classes exist only on some pages: a .single body class on posts, a .home class on the front page.

The 30-second check. In the Inspect panel, search the page’s HTML for your class name. If there is no match, or the match is on a different element than you expected, the selector is the problem. Copy the class the theme actually uses and add it as a second selector, keeping the old one for the pages where it does match.

Cause 4: the CSS was saved under a different theme

WordPress stores Additional CSS per theme. Each theme gets its own custom_css post, named after the theme’s folder, and only the post for the active theme is printed. If you wrote the CSS while a different theme was active, or a child theme, or while trying a theme in the Customizer’s live preview, it is saved under that theme and not the one your visitors see.

The 30-second check. Go to Appearance → Themes and confirm which theme is active. Then open the Customizer and see whether the Additional CSS box is empty or shows different CSS than you remember. If so, your rules are in the other theme’s box. Nothing was deleted; the guide on why WordPress custom CSS disappears when you switch themes covers where each theme keeps it. Copy the CSS across, or move it somewhere theme-independent (see below).

Cause 5: a syntax error stops the whole block

An unclosed brace, a missing semicolon before the next property, or a stray character from a copy-paste can break everything after it. The browser skips the malformed rule and often the rest of the stylesheet with it.

The 30-second check. The Customizer’s editor lints as you type and marks errors in the gutter with a red marker. If it flags a problem, it also refuses to publish until you fix it. Scroll up and look for the marker, then check that every { has a } and every property ends with ;. Rules you pasted from a page builder or a forum post are the usual source.

Cause 6: you are on a block theme

On a block theme such as Twenty Twenty-Five, the Customizer is hidden from the Appearance menu, and the CSS box moved. Since WordPress 6.2 it lives in the Site Editor: Appearance → Editor → Styles, then the three-dot menu, then Additional CSS. What you type there is saved with that theme’s global styles, again per theme.

The 30-second check. If there is no Customize entry under Appearance, you are on a block theme. Open the Site Editor and look there. The old Customizer still opens at /wp-admin/customize.php on most sites, so CSS you wrote there earlier may still be printing, while the Site Editor box shows nothing. Pick one place and keep your CSS there.

Site-wide CSS that doesn’t depend on the theme

Causes 4 and 6 come from the same design choice: WordPress treats Additional CSS as part of the theme’s look, so it lives and dies with the theme. That is right for CSS written against one theme’s markup and wrong for the rules most people write, such as link underlines, button corners and a readable font size on phones.

Adminkeep is a free plugin made of small features with one switch each. Its Custom CSS feature is a standalone custom CSS plugin that gives the site one stylesheet stored by the plugin rather than the theme.

1. Go to Settings → Adminkeep and switch on Custom CSS in the Appearance group.
2. Open Appearance → Custom CSS. It sits in the Appearance menu on classic and block themes alike.
3. Paste your CSS and press Save CSS.

The editor is WordPress’s own code editor, with line numbers, highlighting and the same CSS linting the Customizer uses. The CSS is kept in a site option and printed in the head of every front-end page, after the theme’s Additional CSS, which is left alone. Switch themes and it is still there. It styles the front end only, so check the result on the site, not in the block editor.

One limitation: it fixes causes 4 and 6 and nothing else. A cached page, a losing selector or a class the theme doesn’t use will fail the same way in Adminkeep’s box as in the Customizer’s. Work through the first three checks whichever box you use.

With WP-CLI, wp adminkeep css get prints the stored CSS so it can go straight into a file, and wp adminkeep css set site.css replaces it from one, with the same HTML check as the screen. That makes it easy to keep the stylesheet in version control and copy it between sites. The WP-CLI docs list every command.

Questions people ask

Why does my Additional CSS show in the Customizer preview but not on the live site?

The preview bypasses your cache, the live site doesn't. Clear the page cache and CDN, then reload with the cache bypassed. If the rule then appears, the CSS was fine all along.

Does !important fix WordPress Additional CSS not working?

Only when the cause is specificity, which is one cause of six. It is fine for a one-off override of a theme rule, but it does nothing for a cache, a wrong selector or CSS saved under another theme.

Where did Additional CSS go on a block theme?

On a block theme the box lives in the Site Editor, under Appearance → Editor → Styles → Additional CSS. The Customizer is hidden from the menu, though it still opens from its own URL.

Does Adminkeep's Custom CSS replace my theme's Additional CSS?

No. It leaves the theme's Additional CSS alone and prints its own stylesheet after it, stored by the plugin so it stays when you switch themes.