Twenty Twenty-Five CSS Not Updating: The File Nobody Loads and the Cache That Holds the Rest

Saved, published, and still the old shade of blue

The symptoms split into two families. In the first, a change never appears anywhere, not even for you. In the second, it appears for you while logged in but not for visitors, or appears on some pages and not others. The first family is about where the CSS was written. The second is about caching and specificity.

• Edited style.css, nothing changed: the file you edited is not the file served.
• Child theme rules ignored entirely: the child's stylesheet is not being loaded at all.
• Fine logged in, stale for visitors: a page cache or CDN is holding HTML that contains the old CSS.
• Some properties change, one never does: another rule is more specific, or carries the important flag.
• Everything reverted after a theme change: Additional CSS belongs to the theme it was written for.

If the page looks completely unstyled rather than slightly wrong, that is a delivery failure, covered in theme CSS not loading. For the generic cache side of the story, see CSS changes not showing on a website.

Five layers of Twenty Twenty-Five styling, and the order they print in

Twenty Twenty-Five has almost no stylesheet. Its look comes from theme.json, which WordPress converts into CSS on the fly, plus a tiny file of extra rules. Your changes sit on top in the database. Knowing the layers, and where each one prints, explains nearly every complaint.

The pattern is plain: almost every rule ends up inline, inside the HTML of the page. That is good for speed, as the Twenty Twenty-Five speed guide explains, and it changes how caching behaves. A visitor's browser has no separate CSS file to refresh. The CSS changes when the cached HTML does.

What usually keeps the change from showing

1. You edited style.css

The theme's functions.php enqueues style.min.css, and only switches to style.css when SCRIPT_DEBUG is true. The header of style.css says this in a comment and recommends Additional CSS in the Site Editor instead. Edits there are also wiped by the next theme update. Check: view the page source and search for twentytwentyfive-style; note which file it names, or whether its rules were printed inline.

2. A child theme whose style.css nobody enqueues

The theme's enqueue call uses get_parent_theme_file_uri, which always points at the parent folder. A block theme does not load a child theme's style.css by itself, so rules written there go nowhere until the child enqueues its own file in functions.php or moves the rules into its own theme.json. Check: search the page source for the child theme's folder name. No result, no stylesheet.

3. Cached HTML with old inline CSS

Logged-in users usually bypass the page cache, so you see the new CSS and visitors do not. A hard refresh will not help a visitor, because the CSS is not a separate file. Check: open the page in a private window and search the source for a distinctive part of your new rule. If it is missing, purge the caching plugin, the host's cache and the CDN.

4. A rule that loses the specificity contest

Block settings print classes and inline styles that can outrank a general rule. The theme itself sets link underlines to a text-decoration-thickness of 1px with the important flag, so a plain rule changing underline thickness will lose. Settings for a block type in Styles, Blocks target that block directly and beat general rules. Check: inspect the element in DevTools and look for your rule crossed out, with the winning rule beside it.

5. Theme.json edits hidden by an object cache

WordPress caches the generated global stylesheet in its object cache. On hosts with a persistent object cache such as Redis, a hand edit to a child theme's theme.json can stay invisible until that cache is flushed. Setting WP_DEVELOPMENT_MODE to theme in wp-config.php on a staging site bypasses the cache while you work. Check: flush the object cache from the host panel and reload.

6. A theme switch took the CSS with it

The WordPress documentation is blunt: Site Editor custom CSS is not overwritten by theme updates, but it is cleared when you switch themes, child themes included. Check: did someone activate a child theme or try another theme for a day?

Making the next change stick on the first try

1. 1

   Decide where the rule belongs

   A color, font or spacing change belongs in the Styles panel controls. A small fix that no control covers goes in Additional CSS. A large, versioned set of rules belongs in a child theme file that is properly enqueued.

2. 2

   Add small fixes in Additional CSS

   Open Appearance, Editor, Styles, then the three-dot menu and choose Additional CSS. For one block type only, use Styles, Blocks, pick the block and use Additional block CSS, which takes declarations without a selector.

3. 3

   Undo the style.css edit

   Remove anything added to the theme's style.css or style.min.css so the next update does not surprise you, and move the rules into Additional CSS.

4. 4

   Enqueue the child stylesheet if you use one

   In the child theme's functions.php, enqueue its style.css on wp_enqueue_scripts with get_stylesheet_uri, then confirm it appears in the page source.

5. 5

   Purge in the right order

   Flush the object cache if the host has one, then the caching plugin, then the host's page cache, then the CDN.

6. 6

   Verify as a visitor

   Use a private window, search the page source for your rule, and inspect the element to confirm it wins.

Most of these changes can also be made without CSS at all. Before writing a rule, check Styles, Blocks for the block in question; settings stored there carry over to the editor too, which avoids the editor-versus-site mismatch described in block editor not matching the theme.

Rules for a team that edits styles in the browser

• Never edit the parent theme's files; the theme's own comment asks you not to, and updates overwrite them.
• Keep Additional CSS short and commented, with a date and a reason for each rule.
• Copy Additional CSS somewhere safe before any theme switch, since it does not travel.
• Purge the page cache after every style change; on this theme the CSS lives in the HTML.
• Prefer Styles controls over CSS, so the editor shows what visitors see.

Fonts set in CSS can fight fonts set in Styles; Twenty Twenty-Five fonts not loading covers that side. CSS aimed at the menu often breaks the phone overlay, so retest it with the mobile menu guide. If an edit removed the header rather than restyling it, see Twenty Twenty-Five header not showing.

On this theme the stylesheet is the page. Purge the page, or the old color stays.

A good theme with too many places to type CSS

Count the places a rule can be written for one Twenty Twenty-Five site: the theme file you should not touch, a child stylesheet that needs code to load, Additional CSS, Additional block CSS, per-block Advanced CSS, an old Customizer field, and theme.json. Each has a reason to exist. A site edited by several people over two years ends up using four of them, and nobody knows which rule wins without opening DevTools.

In a Next.js build, styles are files in one repository, compiled at build time and shipped with the HTML that uses them, so a release cannot pair new markup with old CSS. That costs more up front and makes a developer part of every design change. Compare honestly in Twenty Twenty-Five vs Next.js and read moving Twenty Twenty-Five to Next.js before deciding. Meanwhile the Twenty Twenty-Five review and the troubleshooting hub cover the rest, and our theme troubleshooting service or theme repair team can untangle a stylesheet history for you.