--- title: "WordPress Additional CSS not working? Six causes, in order" description: "WordPress Additional CSS not working is usually a cache, a losing selector or CSS saved to another theme. Six checks, 30 seconds each, and a theme-proof fix." pubDate: 2026-09-25 updated: 2026-09-25 source: https://adminkeep.com/guides/wordpress-additional-css-not-working/ --- 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](/guides/wordpress-custom-css/) 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](https://wordpress.org/plugins/adminkeep/) is a free plugin made of small features with one switch each. Its Custom CSS feature is a standalone [custom CSS plugin](/custom-css/) 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](https://wp-cli.org/), `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](/docs/wp-cli/) 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.