How to Fix "Tailwind CSS Styles Not Updating" in a Vite React App

Updated September 13, 2026: Tailwind CSS’s current documentation identifies the framework as v4.3, and its recommended Vite integration is the dedicated @tailwindcss/vite plugin plus @import "tailwindcss";. Vite’s official releases page lists Vite 8.3.0 as released on September 10, 2026. That matters because many “Tailwind styles not updating” fixes copied from older tutorials target Tailwind v3 and can send a v4 project in the wrong direction.

If Tailwind styles render once but stop changing, or new utility classes appear in your JSX without changing the page, troubleshoot the problem in four layers: verify the Tailwind major version and Vite integration, verify that the Tailwind CSS file is actually loaded, verify that Tailwind can detect the class names and source files, then isolate Vite HMR or browser caching. This order avoids unnecessary reinstalls and destructive cache-clearing.

Quick diagnostic table

1. Identify whether the project is Tailwind v4 or a legacy v3 setup

Start here because the correct fix depends on the Tailwind major version. Run:

npm ls tailwindcss @tailwindcss/vite vite

For a current Tailwind v4 + Vite project, Tailwind’s official Vite installation guide recommends installing tailwindcss and @tailwindcss/vite, registering the plugin in vite.config.js or vite.config.ts, and importing Tailwind from your CSS with one line:

@import "tailwindcss";

The corresponding Vite configuration is conceptually:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [react(), tailwindcss()],
});

If your project instead has a tailwind.config.js with a content array and a stylesheet containing @tailwind base, @tailwind components, and @tailwind utilities, you are looking at the v3-era setup. That is not automatically broken if the project is intentionally still on Tailwind v3, but it should not be mixed blindly with v4 instructions. Tailwind’s official v4 upgrade guide specifically explains that the Vite plugin and CSS import flow changed in v4.

Praktisk regel: før du endrer konfigurasjonsfiler, bør du bestemme hvilken hovedversjon du faktisk kjører. Et halvt migrert prosjekt er en vanlig årsak til forvirrende oppførsel fordi pakkeversjonene, PostCSS-konfigurasjonen, Vite-pluginen og CSS-direktivene kan tilhøre forskjellige generasjoner av Tailwind.

2. Bekreft at Vite laster inn CSS-filen som importerer Tailwind

Selv en perfekt Tailwind-konfigurasjon kan ikke oppdatere siden hvis stilarket ikke er en del av Vite-modulgrafen. I en typisk React-oppføringsfil, sjekk for en import som for eksempel:

import "./index.css";

Åpne deretter den nøyaktige filen og bekreft at den inneholder den gjeldende Tailwind-importen:

@import "tailwindcss";

Vites offisielle funksjonsdokumentasjon sier at importert CSS injiseres på siden og støtter Hot Module Replacement (HMR). Med andre ord, hvis index.cssimporten skjer riktig, bør endring av vanlig CSS normalt oppdateres uten at hele siden lastes inn på nytt. Det gir deg en nyttig kontrolltest.

Kjør en todelt kontrolltest

1. Legg til en midlertidig, enkel CSS-regel i det importerte stilarket, for eksempel en synlig kantlinje rundt et testelement.
2. Endre også et statisk Tailwind-verktøy på samme element, for eksempel fra bg-blue-500til bg-emerald-500.

Hvis den vanlige CSS-en endres umiddelbart, men Tailwind-verktøyet ikke gjør det, laster Vite stilarket og HMR er aktivt. Fokuser på Tailwind-deteksjon eller -generering. Hvis ingen av endringene vises, fokuser først på CSS-importen, Vite-utviklerserveren, filbanen eller nettleserens tilstand.

3. Fiks kildedeteksjon og dynamiske klassenavn

Tailwind genererer CSS ved å skanne kildefiler etter klasselignende tokens. Den nåværende dokumentasjonen for deteksjon av klasser i kildefiler forklarer to detaljer som direkte forårsaker symptomer på at «stiler ikke oppdateres».

Ikke bygg klassenavn fra strengfragmenter

Tailwind behandler kildefiler som tekst; den evaluerer ikke JavaScript-koden din for å finne den endelige verdien av en malstreng. Dette mønsteret er upålitelig:

function Badge({ color }) {
  return <span className={`bg-${color}-500 text-white`}>...</span>;
}

De komplette strengene bg-red-500, bg-blue-500og så videre vises aldri i kildekoden, så Tailwind har ingenting definitivt å generere. Tilordne verdier til komplette, statisk detekterbare klassestrenger i stedet:

const variants = {
  red: "bg-red-500 text-white",
  blue: "bg-blue-500 text-white",
};

function Badge({ color }) {
  return <span className={variants[color]}>...</span>;
}

Hvis en hardkodet testklasse oppdateres, men en prop-generert klasse ikke gjør det, er dette det første du må fikse.

Registrer kilder som Tailwind med vilje hopper over

Tailwind v4 oppdager automatisk kildefiler, men dokumentasjonen sier at den ignorerer filer i .gitignore, node_modules, binære filer, CSS-filer og vanlige låsefiler. Dette blir relevant i monorepos og pakker med delt brukergrensesnitt.

Hvis React-appen din bruker en Tailwind-stilpakke som ligger utenfor det automatisk oppdagede kildetreet, registrer den eksplisitt fra stilarket:

@import "tailwindcss";
@source "../packages/ui";

For en pakke inni node_modules, viser Tailwinds dokumentasjon den samme @sourcemekanismen for eksplisitt å inkludere det biblioteket. For et monorepo der dev-kommandoen kjører fra en annen arbeidskatalog, kan du også angi kildekoden som base på importen:

@import "tailwindcss" source("../src");

Bruk eksplisitte kilder bare når du trenger dem. Å legge til store kataloger «bare i tilfelle» gjør det vanskeligere å resonnere rundt prosjektet og kan skape unødvendig skannearbeid.

4. Skill Tailwind-problemer fra Vite HMR, foreldet tilstand og CSS-prioritet

Når v4-integrasjonen, importen av stilark og kildedeteksjon er riktige, start utviklerserveren på nytt. Endringer på konfigurasjonsnivå er en god grunn til å stoppe gjeldende prosess og kjøre:

npm run dev

Ikke begynn med å slette node_modules, låsefilen eller alle hurtigbufferkataloger. Disse trinnene kan skjule den faktiske årsaken og introdusere avhengighetsdrift. Vite har sin egen hurtigbuffer- og avhengighetsoptimaliseringsvirksomhet, men den offisielle feilsøkingsdokumentasjonen påpeker spesifikt vite --forcetilfeller som foreldede optimaliserte avhengigheter etter kobling eller frakobling av lokale pakker. Bruk tvungen reoptimalisering når den situasjonen gjelder, ikke som den første universelle løsningen.

Bruk DevTools til å avgjøre hva som faktisk feiler

Undersøk elementet som burde ha endret seg og still tre spørsmål:

• Finnes den forventede klassen i DOM-en? Hvis ikke, er det React-tilstanden eller komponentlogikken som er problemet, ikke Tailwind.
• Genereres en samsvarende CSS-regel? Hvis klassen finnes, men ingen regel finnes, undersøk kildedeteksjon i Tailwind, dynamisk klassekonstruksjon eller plugin-oppsett.
• Er regelen til stede, men overstreket eller overstyrt? Da genererte Tailwind verktøyet uten problemer. Problemet er CSS-rekkefølge, spesifisitet, en innebygd stil, et annet stilark eller en mer spesifikk velger.

Rask sjekkliste for et Vite React-prosjekt på Tailwind v4

• tailwindcssog @tailwindcss/viteer installert i prosjektet som kjører Vite.
• vite.config.jseller vite.config.tsregistreres tailwindcss()sammen med React-pluginen.
• CSS-filen som importeres av React-inngangspunktet ditt inneholder @import "tailwindcss";.
• JSX-brukene classNameog de komplette Tailwind-verktøynavnene vises bokstavelig talt i kildekoden.
• Filer som inneholder verktøy er inne i Tailwinds automatisk oppdagede kilder, eller legges til med @source.
• Utviklerserveren ble startet på nytt etter endring av Vite/Tailwind-konfigurasjonen.
• DevTools bekrefter om klassen mangler, regelen mangler eller regelen overstyres.

Vanlige rettelser som er versjonsavhengige

Hvis stilene fortsatt ikke oppdateres

Lag den minste mulige testen i samme prosjekt: ett React-element med en litteral klassestreng som className="bg-red-500 p-8 text-white", importert gjennom det vanlige inngangspunktet. Hvis det elementet fungerer, er Tailwind/Vite-integrasjonen fundamentalt sett i orden, og den gjenværende feilen er lokal for kildedeteksjon, dynamisk klassekonstruksjon, komponentlogikk eller CSS-prioritet.

Hvis minimal-elementet fortsatt ikke fungerer, sammenlign filene dine linje for linje med Tailwinds gjeldende Vite-installasjonsinstruksjoner. Bekreft at du ikke ved et uhell kjører Vite fra et overordnet arbeidsområde med en annen package.json, at den installerte Tailwind-hovedversjonen samsvarer med konfigurasjonsstilen, og at CSS-filen du redigerte er den som faktisk ble importert av React.

Den mest effektive feilsøkingsvanen er å unngå å behandle alle sider som ser gammeldagse ut som en HMR-feil. I en moderne Tailwind v4 + Vite React-app deltar CSS-importer allerede i Vite HMR. Når vanlig CSS oppdateres, men et bestemt verktøy ikke gjør det, er Tailwind-klassedeteksjon vanligvis et bedre sted å undersøke enn nettleserens hurtigbuffer.

Offisielle referanser

• Tailwind CSS: Installering med Vite
• Tailwind CSS: Oppdage klasser i kildefiler
• Tailwind CSS: Oppgraderingsveiledning
• Vite: Funksjoner, inkludert CSS og HMR-oppførsel
• Vite: Feilsøking
• Vite 8.3.0-utgivelse