Fixing CSS in React and Next.js Apps

Why React apps end up with CSS problems

A React component can bring its styles in four quite different ways, and each is processed at a different time:

Problems cluster where two approaches meet: a global stylesheet overriding a module, a CSS-in-JS component fighting a Tailwind utility, or a third-party component library shipping its own theme on top of yours. The CSS Checker lists the stylesheets your built pages load, with their sizes, render-blocking and unused CSS, validation errors and specificity issues. In a React build that list shows which bundles each route pulls in, which is the starting point for everything below.

Development and production behave differently

The development server and the production build handle CSS differently, so a bug you see only in one is often not a bug in your CSS at all.

• In development, bundlers such as Vite and the Next.js dev server inject styles through JavaScript so they can hot-reload them. Pages briefly appear unstyled on a hard reload. That flash does not happen in a production build and is not worth fixing.
• In production, CSS is extracted into real stylesheet files, split into chunks and loaded with each route. The order in which chunks load can differ from the order you imported files in development, and that is where genuine ordering bugs appear.

Always confirm a CSS problem against a production build served locally, for example next build && next start or vite build && vite preview, and look at the built output. In Next.js the extracted files sit under .next/static/css/; in Vite they are in dist/assets/. Open the page, filter the Network panel to CSS, and note which files each route loads.

CSS order between routes and chunks

When two rules with equal specificity target the same element, the later one wins. In a single hand-written stylesheet "later" is obvious. In a bundled React app, "later" depends on which chunks have loaded and in what order, and that can change depending on the page a visitor lands on and how they navigate.

A typical case: Button.module.css sets the button colour, and a page-level module for the pricing page also styles buttons inside it with a single class. Visit the pricing page directly and one file loads last; arrive from the home page and the other does. The button changes colour.

Fixes, from most to least robust:

1. Do not style one component's internals from another file. Give the component a prop or variant, such as <Button variant="outline">, and keep every rule about the button in the button's module.
2. Use cascade layers for groups of styles. Declare @layer reset, base, components, pages, utilities; in the global stylesheet imported first, and wrap each file's rules in its layer. Layer order then decides conflicts, whatever order the chunks arrive in.
3. Import shared styles in one place. Global CSS, resets and design tokens go into the root layout or entry file, once, so they are always first.
4. Check your framework's CSS chunking options. Next.js has configuration that affects how CSS is split and merged across routes; read the current documentation for your version before changing it, because the trade-off is between strict ordering and fewer, larger files.

For the general rules about which declaration wins, see Fixing CSS specificity conflicts.

The fix, step by step

Tailwind classes that do nothing

Tailwind reads your source files as plain text and generates CSS for every class name it finds. It never runs your code, so it cannot see a class name assembled at runtime:

// Tailwind never sees "bg-red-600" or "bg-green-600" here
<span className={`bg-${status === 'error' ? 'red' : 'green'}-600`}>

// Full class names in the source: both are generated
const statusClass = {
  error: 'bg-red-600',
  ok: 'bg-green-600'
};
<span className={statusClass[status]}>

The same applies to class names stored in a CMS or database. Either keep a list of them in a file the scanner reads, or safelist them. In recent versions of Tailwind, the CSS-first setup uses @import "tailwindcss"; with automatic source detection, and you add extra folders or inline safelists with the @source directive. Older projects set a content array in tailwind.config.js. Check which one your project uses before changing anything.

Conflicting utilities

When a component receives className="p-4" from a parent and already has p-2, both classes are on the element and the winner is whichever rule comes later in the generated stylesheet, not whichever comes later in the attribute. That is why overrides seem to work for some utilities and not others. A merge helper such as tailwind-merge removes the conflicting class, so the one passed in by the parent reliably wins.

The runtime cost of CSS-in-JS

Runtime CSS-in-JS libraries generate styles while components render. That is flexible, but it has costs that build-time approaches avoid:

• More JavaScript. The library itself ships to the browser, along with the style definitions for every component.
• Work during rendering. Styles are serialised, hashed and inserted as components render, which adds to the work React does on each render, including during interactions.
• Unstyled first paint without server support. If styles are only created in the browser, server-rendered HTML arrives without them and the page appears unstyled until JavaScript runs.
• Friction with Server Components. Libraries that rely on React context and runtime insertion need their components marked as client components, and in the Next.js App Router they need a registry so styles collected on the server are written into the HTML.

Making an existing setup work properly

// next.config.js: keep styled-components class names consistent on server and client
module.exports = {
  compiler: {
    styledComponents: true
  }
};

Pair this with the style registry pattern from the Next.js documentation for your CSS-in-JS library, rendered in the root layout, so styles are collected during server rendering and inserted into the head.

Build-time alternatives

If you are starting fresh or refactoring heavy components, consider an approach that produces static CSS files at build time: CSS Modules, Tailwind, or a zero-runtime library such as vanilla-extract, Linaria, Panda CSS or StyleX. These keep a typed, component-oriented way of writing styles while shipping ordinary cacheable stylesheets. Migrate component by component, starting with those that render most often or appear above the fold.

Stylesheets managed by React

Recent versions of React can manage stylesheet links rendered inside components. A <link rel="stylesheet"> with a precedence attribute is moved into the document head, de-duplicated if several components render it, and ordered by precedence. React also waits for the stylesheet to load before revealing content in a Suspense boundary that depends on it, which prevents a flash of unstyled content for that part of the page.

function MapWidget() {
  return (
    <>
      <link rel="stylesheet" href="/css/map-widget.css" precedence="default" />
      <div className="map-widget">...</div>
    </>
  );
}

This is useful for large, rarely used widgets whose CSS you do not want in the main bundle. Frameworks may handle CSS for you in other ways, so check how your framework expects stylesheets to be included before mixing approaches.

For trimming the CSS that React apps ship, especially leftover global stylesheets and whole component libraries, see Fixing unused CSS and Fixing oversized stylesheets.