How to detect Tailwind CSS on a website

Background

Tailwind's whole design philosophy is utility-first: instead of writing a `.card` class, you compose `flex flex-col gap-3 rounded-xl border border-border bg-card/60 p-5` inline on the element. That verbosity is deliberate; it removes the naming step that traditional CSS requires. It also makes Tailwind-using sites visually obvious in the DOM — a typical element has 6-20 utility classes stacked up, with recognisable prefixes (`md:`, `lg:`, `dark:`, `hover:`, `focus:`, `group-hover:`, `data-[state=open]:`). Once you have spent a few hours with Tailwind code, the visual rhythm of the class attribute is unmistakable.

Competing utility frameworks (UnoCSS, Windi CSS, Master CSS, even old-school Tachyons) share parts of the same class vocabulary, which is why the visual signature alone is not enough. UnoCSS often ships `@unocss` comments in its CSS bundle; Windi's development has slowed significantly since 2023 and it is rare in new builds; Master CSS uses a different prefix system. For distinguishing Tailwind from a hand-written utility stack, the reliable signal is the specific CSS bundle shape: Tailwind's output starts with a large preflight reset block (`*, ::before, ::after { ... }` with universal `box-sizing` and margin reset), has `@layer base / @layer components / @layer utilities` structure, and (in v4) uses `@theme` blocks with `--color-*`, `--spacing-*` and `--font-*` CSS variables.

The v3-vs-v4 distinction is worth getting right because the two engines are quite different products. Tailwind v3 (the JIT compiler era) reads a `tailwind.config.js`, builds a CSS file from explicit `@tailwind base; @tailwind components; @tailwind utilities;` directives, and ships PostCSS plugins as the integration surface. Tailwind v4 is a complete rewrite around a Lightning CSS-based engine, removes the JS config in favour of `@theme` declarations, makes CSS variables first-class, and changes how dark mode and arbitrary values are authored. The two also produce visibly different bundle shapes: v3 output is heavier on `@layer` directives and explicit utility blocks, v4 leans hard on CSS variables and ships a different preflight. Recognising the version on a site shapes any work you might propose on top of it.

Why this matters

Tailwind has become the default CSS layer for modern React/Vue/Svelte apps. Detecting it narrows the UI kit shortlist (shadcn/ui, Radix + Tailwind, Catalyst, DaisyUI, Flowbite, headless-with-Tailwind setups) and helps you correlate the frontend choices. Sites that use Tailwind almost always pair it with one of a small set of component libraries; sites that do not use Tailwind are usually on a more traditional CSS architecture (CSS Modules, styled-components, vanilla-extract, plain global stylesheets) and have a different conversation about styling.

Tailwind v3 vs v4 is a meaningful distinction. v4 has a different compiler (Lightning CSS-based), CSS-variable-driven theming, and shifts how you author and debug styles. A site on v4 can adopt newer patterns (CSS-variable design tokens shared between Tailwind and bespoke CSS, simpler dark-mode setup, faster incremental builds) that a v3 site cannot reach without an upgrade. For consulting and audit work, knowing which version is in play tells you whether the upgrade conversation is 'we just need to bump dependencies' or 'we need to plan a configuration migration'.

For performance work the Tailwind production bundle is informative. A purged production build of v3 weighs tens of kilobytes (sometimes single-digit KB on small sites), while a misconfigured purge can ship the entire utility surface (~3 MB unminified). v4's compiler is more aggressive about dead-class elimination, which usually means smaller bundles but a slightly different debugging story when the classes you wrote do not appear in the output. Both versions interact with `<style>`-tag CSS-in-JS generated by component libraries, which is its own performance topic.

Prerequisites

• Chrome DevTools — the workflow uses the Elements panel to inspect class attributes and the Network tab to look at the CSS bundle.
• Comfort reading CSS source — at least to the level of recognising `@layer`, `@tailwind`, `@theme` and the visual shape of a generated utility-class block.
• Optional: Sourcemap Explorer installed, which surfaces the exact Tailwind version from the CSS sourcemap and identifies the UI library on top in one popup click.
• Optional: a working knowledge of Tailwind class syntax (`md:grid-cols-2`, `hover:bg-black/10`, the `[arbitrary]` value system) — useful for interpreting what you see, but not strictly required.

Step-by-step

1. 1

   Inspect any element for the class signature

   Right-click any visible component (a button, a card, a navigation item) → Inspect. Look at the `class` attribute. Tailwind classes follow `(state:)?<utility>-<variant>` patterns: `flex`, `gap-3`, `text-sm`, `font-medium`, `md:grid-cols-3`, `dark:bg-slate-900`, `hover:underline`, `data-[state=open]:rotate-90`. A few of those stacked in one attribute is effectively a positive — no other CSS framework produces that exact density of class names per element. If the attribute looks more like one or two semantic class names (`primary-button`, `feature-card`), the site is probably on a traditional CSS architecture instead.

2. 2

   Check the CSS bundle in the Network tab

   In the Network tab, filter by 'CSS' and reload. Click into the largest stylesheet. Tailwind output starts with a large block of `@layer base / @layer components / @layer utilities` (v3) or `@theme` declarations followed by utility blocks (v4), preceded by reset styles (`*, ::before, ::after { box-sizing: border-box; ... }`). The long tail of the file is compiled utility classes, sometimes thousands of them on larger sites. The preflight + layer structure is the most reliable single signal that distinguishes Tailwind from utility-styled hand-rolled CSS.

   Tip: Production Tailwind bundles are typically 20-100 KB after purging unused classes. If you see a 3 MB CSS file with every conceivable utility, the build is misconfigured — purge is not running. That is occasionally an interesting performance note to flag in an audit.

3. 3

   Look for Tailwind v4 signals

   Tailwind v4 introduces several distinct signals: `@theme { ... --color-*: ...; }` blocks at the top of the bundle, `--tw-content` and other `--tw-*` variables used as design-token primitives, viewport-aware sizing utilities like `h-dvh` / `min-h-svh`, and the absence of `tailwind.config.js`-derived patterns (config-defined custom colours show up as CSS variables instead of compiled colour utilities). Older v3 output uses `h-screen` more heavily, has fewer `--*` variables in the cascade, and includes the `--tw-` prefixed vars used by the JIT compiler for arbitrary-value handling.

4. 4

   Identify the UI library on top

   Tailwind almost always pairs with one of a small set of component libraries. shadcn/ui is the dominant choice on Next.js sites and shows up via `class-variance-authority`, `clsx`, `tailwind-merge`, plus component file patterns in the sourcemap (`button.tsx`, `dialog.tsx`, `dropdown-menu.tsx` named after the shadcn registry). Radix Themes ships its own `<RadixTheme>` wrapper element and `radix-themes.css` sheet. Catalyst is Tailwind UI's premium kit with distinctive `dark/zinc-*` colour utilities. DaisyUI uses its own `data-theme="<name>"` attribute on `<html>`. Spotting the UI layer narrows the rest of the audit considerably.

5. 5

   Use Sourcemap Explorer to confirm the version

   If sourcemaps are exposed, the extension reads `node_modules/tailwindcss/package.json` from the CSS map and shows the exact version — e.g. Tailwind CSS 4.0.6 — instead of the v3-or-v4-best-guess most other detectors return. The extension also identifies the surrounding ecosystem packages (`@radix-ui/*`, `class-variance-authority`, `clsx`, `tailwind-merge`, `@headlessui/*`) which is what tells you whether the site is on shadcn/ui, headless-Radix, Catalyst, or a custom Tailwind setup. The whole detection takes one click.

6. 6

   Cross-check with the dev console

   If you want a second confirmation, open the dev console and run `getComputedStyle(document.body).getPropertyValue('--color-background')` (or any `--color-*` token you saw in the bundle). If that returns a real value, the site is using v4-style CSS-variable theming; if it returns empty, you are looking at v3-style compiled colour utilities. The same trick works for `--spacing-*` and `--font-*` tokens.

Real-world example

Alternative methods

Troubleshooting

Caveats

What to do next

Once you've confirmed Tailwind, the natural next moves are identifying the UI ecosystem (shadcn/ui via its CVA + Radix combo, Catalyst via its colour utilities, DaisyUI via the `data-theme` attribute), surfacing the JavaScript framework underneath (Tailwind is most common on Next.js but ships everywhere), and looking at the design-token system (CSS variables on v4, `tailwind.config.js`-derived utilities on v3). The [see-every-javascript-library-a-site-uses](/how-to/see-every-javascript-library-a-site-uses) and [find-the-exact-version-of-an-npm-package-on-a-site](/how-to/find-the-exact-version-of-an-npm-package-on-a-site) guides cover the version-level work; [check-if-a-site-is-built-with-nextjs](/how-to/check-if-a-site-is-built-with-nextjs) and [detect-framework-of-any-website](/how-to/detect-framework-of-any-website) cover the framework side. For performance work the Tailwind footprint is usually the smallest line item on the CSS budget, but it is worth checking whether the site is on the JIT compiler (v3) vs the new Lightning CSS engine (v4) to understand the build pipeline. For audit work, knowing the version drives the upgrade-effort estimate. For competitive analysis, the Tailwind + shadcn/ui combination has become so standard that its presence tells you a lot about the team's frontend culture in one read.

FAQ

Related