How to Add Custom CSS to WordPress (Without Breaking Things)

Sometimes the WordPress Customizer doesn’t expose the setting you need. The theme uses a font size you want to change. A button’s hover color is off. You want to tweak the spacing on archive pages. The fix is small CSS, just a few lines that override what the theme does. Done right, it’s harmless. Done wrong, it cascades into other broken things.

Where to add custom CSS

1. Customizer → Additional CSS (easiest)

Appearance → Customize → Additional CSS.

Pros:

• Survives parent theme updates.
• Live preview as you type.
• No code editing required.
• Stored in the WordPress database, attached to the active theme.

Cons:

• Doesn’t carry over if you switch themes.
• Can get unwieldy with hundreds of lines.

This is the right place for most custom CSS. Roughly 90% of bloggers never need anything more elaborate than this panel. A theme like Aurora is built so most visual changes, fonts, colors, spacing, layout widths, already live in the Customizer, which means you’ll reach for Additional CSS far less often than you would with a theme that hides everything behind hand-written code.

2. Child theme’s style.css

If you have a child theme, you can add CSS to its style.css file.

Pros:

• Better for large amounts of CSS.
• Version-controllable if you keep files in git.
• Performance-wise, identical to Customizer CSS.

Cons:

• Requires SFTP or file editing.
• Still doesn’t carry over if you switch parent themes.

This route is best for serious customization, multi-site management, or developers who want their CSS under version control. If you haven’t set one up yet, our guide to setting up a WordPress child theme walks through the whole process in about ten minutes.

3. A plugin like Simple Custom CSS

Various plugins add a CSS editor to WordPress. These are mostly redundant with the Customizer, and they’re really only useful if your theme lacks the Customizer option in the first place.

What not to do

• Don’t edit the parent theme’s style.css directly. Those changes get wiped out at the next update.
• Don’t add inline styles to individual posts. It works in the moment, but it doesn’t scale.

How CSS works, the one-minute version

CSS rules have three parts:

selector {
  property: value;
}

The selector targets HTML elements. Common ones look like this:

• p — targets all paragraphs.
• .classname — targets elements with that class.
• #idname — targets the element with that ID.
• h2.entry-title — targets h2 elements with the class “entry-title.”
• .site-header a — targets links that live inside the site header.

Properties define what actually changes: color, font-size, margin, and so on.

Finding the right selector

This is the hardest part of writing custom CSS. To find the selector for an element on your page, use your browser’s built-in tools.

Browser DevTools

1. Right-click the element on your live site and choose “Inspect” (or press Cmd+Shift+I on Mac, Ctrl+Shift+I on Windows).
2. The DevTools panel opens, and the HTML for the element you clicked is highlighted.
3. Look at its classes, listed in the class="..." attribute.
4. The CSS panel on the right shows you what styles currently apply to that element.

From there, you can identify exactly what class to target in your own CSS. WordPress.org’s own Customizer documentation covers the Additional CSS panel in more depth if you want the full reference.

Common WordPress classes

• .entry-title — the post title in archives and single posts.
• .entry-content — the main post content area.
• .site-header — the header.
• .site-footer — the footer.
• .widget — sidebar widgets.
• .post-X — a specific post, targeted by ID.
• .category-Y — posts belonging to a specific category.

Every theme adds its own classes on top of these WordPress defaults, so inspecting the actual markup is still the fastest way to find what you need.

The “specificity” issue

Sometimes you write CSS and nothing happens. Usually that’s because a more specific rule elsewhere is overriding yours.

CSS specificity rules, simplified:

• Inline styles beat IDs, IDs beat classes, and classes beat plain element selectors.
• More specific selectors win over less specific ones.
• .site-header .menu-item a beats a plain a.

To override an existing rule, make your own selector more specific. Add a parent class, or stack selectors together. MDN’s specificity guide is worth bookmarking the first time this trips you up, because it will happen more than once.

The !important nuclear option

Adding !important to a property overrides everything else:

.entry-title {
  color: #333 !important;
}

Use it sparingly. Once you’ve reached for !important once, you often need to use it again just to override your own earlier !important declarations, and that turns into a cascading nightmare fast. Fixing specificity properly is almost always the better move.

Common customizations

Change a font

body {
  font-family: 'Inter', sans-serif;
}

Note that the font has to actually be loaded for this to work. Customizer typography settings often handle that loading for you. For custom Google Fonts beyond what your theme offers, use a plugin like OMGF or your theme’s built-in font loader.

Adjust heading sizes

h1 { font-size: 2.5rem; }
h2 { font-size: 2rem; }
h3 { font-size: 1.5rem; }

Change link color

a {
  color: #d44;
}
a:hover {
  color: #b22;
}

Adjust spacing

.entry-content p {
  margin-bottom: 1.5em;
}

Hide an element

.site-info {
  display: none;
}

Use this cautiously. Hiding elements without understanding why they exist can break things elsewhere, like when hiding the comment form accidentally breaks discussions on the page.

Mobile-only or desktop-only changes

/* Mobile only */
@media (max-width: 768px) {
  .sidebar { display: none; }
}

/* Desktop only */
@media (min-width: 769px) {
  .site-title { font-size: 3rem; }
}

How to write CSS that doesn’t break things

1. Be specific in your selectors

Avoid generic selectors that affect far more than you intend.

Bad: div { padding: 20px; } affects every div on the entire site.

Good: .entry-content { padding: 20px; } only touches the post content area.

2. Test on multiple devices

After adding new CSS, check how it looks on:

• Desktop.
• Tablet width, using your browser’s responsive mode.
• Phone width.
• A real phone, if you have one handy.

CSS that looks perfect on desktop can quietly break on mobile.

3. Test multiple page types

CSS that affects blog posts often also touches archive pages, sometimes the homepage, and sometimes single pages too. Check each page type individually rather than assuming one preview covers everything.

4. Don’t !important your way out of problems

If you find yourself needing !important, you probably have an underlying specificity issue. Fix that instead of masking it.

5. Comment your CSS

For anything non-obvious, leave a short comment explaining why:

/* Increase mobile body font for readability */
@media (max-width: 768px) {
  body { font-size: 17px; }
}

Future you will genuinely thank present you for this.

The “I added CSS and now my site is broken” recovery

If Customizer Additional CSS is the culprit, open the Customizer, delete the offending CSS, and save.

If it’s your child theme’s style.css, revert your changes via SFTP.

If you’re not sure which CSS actually broke things, comment out your most recent additions one section at a time until the issue resolves itself.

Performance considerations

Custom CSS rarely affects performance in any meaningful way. A few hundred lines of CSS in the Customizer loads just fine.

If you’ve accumulated thousands of lines, consider:

• Moving everything to a child theme’s style.css, which is slightly more efficient to serve.
• Auditing the file to remove rules you no longer use.
• Combining it with the theme’s other CSS via a caching plugin.

Custom CSS is just one setting among many that new WordPress installs leave in a non-ideal state by default. If you haven’t already gone through the rest of them, our rundown of essential WordPress settings to check on a new install covers the other defaults worth revisiting before they cause problems.

Don’t optimize prematurely, though. If your CSS is short and your site feels fast, there’s nothing here worth chasing.

A note on theme quality and CSS overhead

How much custom CSS you end up writing often comes down to how much the theme itself already gets right. A theme that outputs clean, minimal markup gives you fewer surprises to fight with in DevTools. This is part of why themes like Aurora invest in clean, predictable CSS output, so the selectors you find in DevTools stay stable across updates instead of shifting every release and quietly breaking your overrides.

Where custom CSS ends and a child theme begins

Once your Additional CSS panel starts running past a few hundred lines, or you find yourself wanting to override actual template files rather than just styles, that’s usually the signal to step up to a proper child theme. See our guide on setting up a WordPress child theme for the details on when that jump makes sense.

What actually needs a full CSS audit

Custom CSS is fine when it’s a handful of small overrides. If you’re routinely fighting the theme’s layout, adjusting site width, sidebar behavior, or archive spacing, over and over with patchwork fixes, it’s worth checking whether the theme’s own Customizer settings already offer a cleaner path. Many blog themes, Aurora included, expose layout and spacing controls natively so you’re not reconstructing basic structure with CSS overrides in the first place.

Where this leaves you

Customizer → Additional CSS is the right place for most blogger CSS. Be specific in selectors. Use browser DevTools to find the right classes to target. Test mobile and multiple page types after changes. Avoid !important when possible. Comment non-obvious code. If something breaks, comment out recent CSS until it works. Most CSS customizations are 5 to 10 lines; learn the basics once and you can tweak forever.