How to keep your custom CSS when you switch WordPress themes

01Where your custom CSS actually lives

"My custom CSS disappeared when I switched themes" is one of the most common theme-migration panics, and it's almost never lost. It's just stored somewhere that's tied to the theme you left behind. The first job is knowing all the places it could be hiding.

Most WordPress sites accumulate CSS in more than one spot over the years. Different people, different tutorials, and different plugins all dropped a few rules wherever was easiest at the time. Find all of them before you switch — missing one means a styling tweak quietly vanishes and you won't know why.

The four usual hiding spots

• Customizer → Additional CSS — the box at Appearance, Customize, Additional CSS. This is the most common home for one-off tweaks, and it is stored per-theme, so it's the first thing to break on a switch.
• Theme settings or options panel — many premium themes have their own "Custom CSS" field buried in the theme options. That field belongs to the theme and leaves with it.
• A child theme's style.css — if someone set up a child theme, CSS may live in its stylesheet. This only travels if you keep using that exact child theme.
• A plugin — a CSS or code-snippets plugin (Simple Custom CSS, Code Snippets, or your page builder's custom-CSS box) stores rules independently of the theme. These usually survive a switch.

Notice the pattern: anything stored by the theme leaves with the theme; anything stored by a plugin or a child theme you keep tends to stay. That single distinction explains every "why did this break and that didn't" you'll hit.

02Why some of it breaks even when you do everything right

Here's the part that surprises people: even if you carefully copy every line of CSS into the new theme, some of it still won't do anything. That's not a mistake on your part — it's how CSS targeting works.

CSS rules point at specific HTML — a class, an ID, or an element. Your old rule might say "make .site-header-inner blue." If the new theme calls that element something else entirely, the rule still loads, finds no match, and silently does nothing.

So custom CSS splits into two buckets after a switch. Generic rules — typography, button colors, spacing on standard elements — usually still apply because they target common selectors. Theme-specific rules that hooked into the old theme's unique class names go dead, because those class names no longer exist.

This is why "keeping your CSS" is really two jobs: preserving the rules so none are lost, then auditing which ones still hit something. Skipping the audit leaves you with a stylesheet full of dead rules that clutter the file and confuse the next person who edits it.

03Before you switch: find and export all of it

The goal here is one consolidated file containing every line of custom CSS from every location, captured while the old theme is still active and everything is still in place. Do this first, before you touch the theme.

Open a plain text file and work through your hiding spots one at a time, pasting each block in with a comment noting where it came from. A comment like / from Customizer Additional CSS / above each chunk takes seconds and saves real confusion later.

The export checklist

• Copy everything in Appearance, Customize, Additional CSS — select all, paste into your file, label it.
• Open your theme's options panel and check for a custom-CSS field there; copy anything you find.
• Check for a child theme — if one exists, open its style.css (Appearance, Theme File Editor, or via your host's file manager) and copy any custom rules.
• List your plugins — note any CSS or snippets plugin so you know what's already theme-independent and doesn't need moving.
• Save the file somewhere off the server, alongside the full backup you should already be taking before any theme switch.

It's worth running a quick search of your saved file for the old theme's name or its signature class prefix. That's the fastest way to flag the rules most likely to break, so you know where to look first when you audit on the new theme.

04The right home: theme-independent CSS

Pasting your CSS into the new theme's Additional CSS box works, but it recreates the exact problem you just solved — the next theme switch will orphan it all over again. The better move is to give your CSS a home that doesn't care which theme is active.

You have two solid options, and both decouple your custom styles from any single theme. Pick based on how comfortable you are with files.

Option 1: a child theme

A child theme is a small theme that inherits everything from a parent theme but lets you override pieces of it. Put your custom rules in the child theme's style.css and they load on top of the parent. The catch: a child theme is tied to its specific parent, so this is durable only as long as you keep that parent theme.

Option 2: a CSS or snippets plugin

A dedicated plugin — Simple Custom CSS, Code Snippets, or similar — stores your CSS in the database, independent of any theme. Activate it, paste your rules in, and they survive every future theme change untouched. For most non-developers this is the simpler, more portable choice, and it's the one I reach for first.

• Want the most portable, no-code option? Use a CSS/snippets plugin — it ignores theme switches entirely.
• Already running a child theme and comfortable with files? Keep your rules in its stylesheet.
• Either way, avoid the Customizer's Additional CSS box for anything permanent — treat that box as scratch space, not storage.

05Auditing which rules still apply

Once your CSS is loaded into its new home on a staging copy, walk through it and separate the rules that still work from the ones that are now dead weight. This is the step most people skip, and it's the one that keeps your stylesheet clean.

The fastest way to check a rule is your browser's built-in inspector. Right-click an element you styled, choose Inspect, and look at the styles panel. If your rule shows up and applies, it's still live. If the element's class names are completely different from what your rule targets, that rule is obsolete.

How to triage each rule

• Still applies and still wanted — keep it as is.
• Targets a class the new theme doesn't have — either delete it or rewrite the selector to match the new theme's markup.
• Was a workaround for an old-theme bug — the new theme may not have that bug, so the rule is pure clutter. Remove it.
• You're not sure — comment it out rather than deleting, note why, and revisit after a few days of using the site.

Don't try to fix everything at once. Get the high-visibility pages looking right first — homepage, key landing pages, your main template — then mop up smaller cosmetic rules afterward. A dead rule does no harm beyond clutter, so there's no urgency to chase every last one.

06Test it on staging, not live

Everything above — loading the CSS, auditing it, rewriting selectors — should happen on a staging site, not in front of real visitors. A staging site is a private clone where you can break things freely and nobody notices.

This matters more for CSS than people expect. A mistyped selector or a leftover rule can shift your layout, hide a button, or clash with the new theme's own styles. On staging that's a five-minute fix. On a live site it's an embarrassing afternoon.

Many managed WordPress hosts include one-click staging in the plan, which is the painless way to do this — Cloudways is one we point readers to for that. If your host doesn't offer it, a plugin like WP Staging can spin up a local clone instead. Either way, get the CSS right on the copy, then push it live.

What to check on staging

• Compare side by side — keep the old live site open in one tab and staging in another, and look for any styling that changed.
• Check mobile and desktop both — a rule can apply cleanly on desktop and break a phone layout, where most of your traffic is.
• Test the elements you specifically styled — buttons, headings, spacing, anything you remember tweaking.
• Confirm nothing renders worse than before; if it does, that's a finding to fix, not a detail to wave off.

07Keeping your CSS maintainable from here

Once you've done this migration the hard way once, a little discipline keeps you from ever doing it the hard way again. The aim is CSS that's easy to find, easy to read, and never trapped inside a theme.

• Keep one source of truth — pick a child theme stylesheet or a snippets plugin and put all custom CSS there, not scattered across three places.
• Comment every block — a one-line note saying what a rule does and why future-you will thank you when you revisit it.
• Keep a master copy off the site — store your CSS in a plain text file in your own files too, so it's never only in one database.
• Prefer durable selectors — target standard elements and stable classes over a theme's deep, unique class names where you can, so rules survive future changes.
• Review periodically — every so often, prune rules that no longer apply so the file doesn't rot into a pile of dead overrides.

None of this is heavy. It's the difference between custom CSS that's a maintainable asset and custom CSS that's a liability you rediscover every time you redesign. Spend the ten minutes once and the next theme switch is a non-event for your styling.

08FAQ

Will my custom CSS be deleted when I switch themes?

No. CSS in the Customizer's Additional CSS box stays in your database — it just stops loading because it's tied to the old theme. Reactivate that theme and it reappears. It's hidden, not deleted, which is exactly why you can safely copy it out before switching.

Why does some of my CSS work on the new theme and some doesn't?

Rules that target common elements and standard selectors usually still apply. Rules that targeted the old theme's unique class names find nothing to match on the new theme, so they silently do nothing. The fix is to rewrite those selectors to match the new theme, or delete them.

Should I use a child theme or a plugin for my custom CSS?

Both decouple CSS from the active theme. A child theme is great if you're comfortable with files and plan to keep its parent theme. A CSS or snippets plugin is the more portable, no-code option that survives every future theme switch — for most non-developers, that's the simpler pick.

Where do I paste CSS back in after switching?

You can paste it into the new theme's Additional CSS box to get the site looking right quickly, but for anything permanent, move it into a child theme stylesheet or a snippets plugin so the next switch doesn't orphan it. Treat the Customizer box as temporary scratch space.

How do I find which rule is styling a specific element?

Use your browser's inspector: right-click the element, choose Inspect, and read the styles panel. It shows every rule applied to that element and where it came from, so you can tell whether your custom rule is winning, losing, or no longer matching anything at all.

This is general, experience-based guidance from running a theme shop — not financial or professional advice for your specific site. When the cost of a mistake is high, work on staging and keep a tested backup before you change anything.