How to Tell if a Website Uses Tailwind CSS

To tell whether a website uses Tailwind CSS, open DevTools, inspect an element, and read its class list. Tailwind styling looks like utility-class soup: a single element stacked with many tiny classes such as flex items-center justify-between pt-4 text-sm gap-x-2, plus responsive prefixes like md:grid-cols-3 and hover:bg-blue-600. The strongest single tell is an arbitrary value in square brackets — a class like w-[327px] or bg-[#1a1a1a] — which is almost unique to Tailwind. Seeing this pattern across several elements, with no semantic component class names, identifies Tailwind with high confidence. This guide walks through every signal, how to read each in the Elements panel, and the purging-and-renaming caveat that can make detection less certain.

It sits alongside how to find what fonts and colours a website uses and the wider how to find out what technology a website uses.

What Tailwind CSS is, briefly

Tailwind CSS is a popular utility-first CSS framework. Instead of writing custom CSS or using pre-styled components (a card, a btn-primary), you compose designs directly in the markup from a large set of small, single-purpose utility classes: one for flex layout (flex), one for padding-top of a given size (pt-4), one for small text (text-sm), and so on. A build step then scans your files and generates a stylesheet containing only the utilities you actually used. This approach produces a very distinctive HTML signature — elements carrying long strings of terse, functional classes — which is exactly what makes Tailwind identifiable. It is fundamentally different from a component framework like Bootstrap, and recognising that difference is the key to telling CSS frameworks apart, a theme this guide returns to.

Signal 1: utility-class soup in the HTML

The defining Tailwind fingerprint is what developers half-jokingly call utility-class soup: HTML elements with long class attributes made up of many small, functional classes rather than a few descriptive ones. Inspect a button, a card or a layout container on a Tailwind site and you might see something like:

<div class="flex items-center justify-between gap-x-3 rounded-lg bg-white px-6 py-4 shadow-sm">

Every one of those classes does exactly one thing — flex sets display, items-center aligns, px-6 and py-4 set padding, rounded-lg rounds corners, shadow-sm adds a shadow. There is no card or header class describing what the element is, only classes describing how it looks. When you see this density of single-purpose classes repeated across many elements, you are almost certainly looking at a utility-first framework, and Tailwind is by far the most common one.

Signal 2: responsive and state prefixes

Tailwind's most distinctive syntactic feature is its colon-prefixed variants. Responsive utilities use a breakpoint prefix — sm:, md:, lg:, xl:, 2xl: — so md:grid-cols-3 means "use a three-column grid at the medium breakpoint and up". State and context variants work the same way: hover:bg-blue-600, focus:ring-2, dark:text-white, disabled:opacity-50. This variant:utility pattern is core to how Tailwind handles responsiveness and interaction, and it shows up densely in the markup of a Tailwind site. Other frameworks do not produce this exact colon-prefix pattern in the class attribute, so finding many classes like md:flex, lg:hidden and hover:underline is a strong, characteristic Tailwind signal — arguably the most reliable one short of arbitrary values.

Signal 3: arbitrary values in square brackets

The closest thing to a smoking gun is Tailwind's arbitrary-value syntax. When the framework's preset scale does not contain the exact value a developer needs, Tailwind lets them write a one-off value in square brackets. So you get classes like:

• w-[327px] — an exact width
• bg-[#1a1a1a] — a specific hex colour
• top-[13px] — precise positioning
• grid-cols-[1fr_2fr] — a custom grid template

This bracket notation is distinctive to Tailwind's arbitrary-value feature; no other mainstream framework uses square-bracketed classes in this way. So if you inspect elements and spot classes containing [ and ], that is close to conclusive evidence of Tailwind. It is worth searching for specifically: in the Elements panel, scan a few complex components for bracketed classes, because a single clear one settles the question.

Signal 4: a single compiled stylesheet, no semantic classes

Tailwind's build process typically compiles everything into one CSS file full of utility definitions, rather than many per-component stylesheets. So a Tailwind site usually references a single main stylesheet whose rules are overwhelmingly single-property utilities (.pt-4 { padding-top: 1rem; }, .text-sm { font-size: 0.875rem; }) rather than component rules (.card { ... }). Two structural consequences help detection. First, the absence of semantic component classes in the HTML — you will not find a hand-named .product-card driving the styling, because the styling lives in utilities. Second, when you inspect an element in DevTools and look at the Styles/Computed panel, the applied rules are a stack of tiny utility classes, each contributing one declaration. That pattern in the computed styles is itself a Tailwind tell.

The signal table

Signal	Where to find it	What it means
Utility-class soup (flex pt-4 text-sm gap-x-2)	Elements panel, View Source	Utility-first framework — strong Tailwind indicator
Colon variants (md:grid-cols-3, hover:bg-blue-600)	Elements panel	Tailwind responsive/state syntax — strong
Arbitrary values (w-[327px], bg-[#1a1a1a])	Elements panel	Tailwind arbitrary-value syntax — close to conclusive
Single utility-heavy stylesheet	Network tab, Sources	Compiled Tailwind output
No semantic component class names	Elements panel	Consistent with utility-first styling
Utility rules in Computed/Styles panel	DevTools Styles	Tailwind utilities applying one property each

Any single strong signal points at Tailwind; arbitrary-value brackets plus colon variants together are near-certain.

Method 1: inspect computed styles in the Elements panel

The best method is to inspect elements directly. Open DevTools (F12), use the element picker (the arrow icon, or Ctrl/Cmd + Shift + C), and click a visually interesting component — a button, a navbar, a card grid. Read its class attribute in the Elements panel: look for the utility-class soup, the colon-prefixed variants, and especially any square-bracket arbitrary values. Then glance at the Styles pane on the right, which shows the matched rules — on a Tailwind site these are a column of small utility classes, each applying a single declaration. Inspecting a few different components rather than one is wise, because some elements carry more utilities than others; sampling a button, a layout container and a text block gives a representative read. This element-level inspection is the same technique at the heart of finding what fonts and colours a website uses.

Method 2: View Source

A static source view is a fast first pass. Open the page, press Ctrl/Cmd + U, and scan the markup for the tell-tale class strings. You can use the in-page find to search for characteristic substrings: a [ (for arbitrary values), md: or lg: (for responsive variants), or common utilities like flex and text-. Because the classes live directly in the server-returned or hydrated HTML, View Source often surfaces them immediately. The caveat is that on heavily client-rendered sites the initial source may be sparse and the utility classes only appear once the framework renders, in which case the live Elements panel (Method 1) is the better tool. For a quick yes/no on a server-rendered site, though, searching the source for [ and md: is remarkably effective.

Method 3: the stylesheet and detection tools

For corroboration, look at the stylesheet and lean on detection tooling. In the Network tab, find the site's main CSS file and open it; a Tailwind build is full of utility-class definitions, often with the framework's characteristic reset (Preflight) at the top. General detection tools — Wappalyzer, BuiltWith and similar — list CSS frameworks among their findings and will frequently flag Tailwind, which is a useful second opinion alongside your manual inspection. Treat the tool result as supporting evidence: combine it with what you have seen in the Elements panel rather than relying on it alone, since CSS-framework detection is inherently pattern-based. This is the same multi-tool approach described in how to find out what technology a website uses.

The big caveat: purging, prefixes and renaming

Honesty about the limits matters here. Tailwind's production build purges unused classes to keep the stylesheet small — but this does not hide the framework, because the classes a page does use still appear in its HTML; purging only removes the ones it never uses. More relevant are two configuration choices. Some teams set a prefix (so utilities become tw-flex, tw-pt-4), which disguises the bare-utility look until you notice the consistent prefix. And a small minority obfuscate or rename classes in their build, which can genuinely mask the pattern. There is also the @apply direction: a developer can fold utilities into their own semantic classes in the CSS, so the HTML shows a .btn class while the underlying stylesheet is pure Tailwind — in that case the framework hides in the CSS rather than the markup. So a site without obvious utility soup is not guaranteed to be Tailwind-free; check the stylesheet itself before concluding. In the common case, though, the utilities and bracket values are plainly visible.

Distinguishing Tailwind from other CSS approaches

It helps to know how Tailwind differs from its neighbours so you do not misattribute. Bootstrap is component-first: you see semantic classes like container, row, col-md-6, btn btn-primary and navbar rather than utility soup — a completely different signature (see how to tell if a website uses Bootstrap). Bootstrap's own utility classes (newer versions added some, like d-flex or mt-3) can look superficially similar, but they sit alongside its component classes and use different names, and you will not see Tailwind's colon variants or bracket values. Plain hand-written CSS shows semantic, author-named classes and no systematic utility scale. CSS-in-JS solutions often produce hashed, generated class names (random-looking strings) rather than human-readable utilities. So the deciding question is the shape of the class names: terse single-purpose utilities with colon variants and square brackets say Tailwind; semantic component names say Bootstrap or hand-written CSS; hashed gibberish says CSS-in-JS.

A worked example

You are curious how a slick-looking marketing site was built. You open DevTools, pick the element tool, and click the hero's call-to-action button. Its class attribute reads inline-flex items-center rounded-md bg-indigo-600 px-4 py-2 text-sm font-medium text-white hover:bg-indigo-500 — pure utility soup, with a hover: variant. You click the three-column feature grid below it and see grid grid-cols-1 gap-8 md:grid-cols-3 — the md: responsive prefix, unmistakably Tailwind. Scanning a custom-positioned badge, you spot top-[6px] — an arbitrary value in brackets, the clincher. There are no semantic component classes anywhere; the styling lives entirely in utilities. So the read is clear: this site is built with Tailwind CSS, almost certainly with a modern build step and probably a component framework underneath. Two or three inspected elements were enough to be sure.

Why the CSS framework matters

Knowing a site uses Tailwind tells you about its front-end workflow and the team's choices. Tailwind implies a utility-first approach and a build step (the CSS is compiled), which usually accompanies a modern toolchain. It is very commonly paired with a component framework like React, Vue or Svelte, so spotting Tailwind is a hint to check for those too — the styling and the framework often travel together. The choice also signals a certain design and engineering culture: utility-first is a deliberate, current approach favoured by teams who value rapid, consistent UI work. For competitive research, for developer hiring, for agency project scoping, or simply for learning from a real, well-built front end, the CSS framework is a meaningful part of the stack — and Tailwind specifically points to a modern, component-driven build.

How reliable is Tailwind detection?

Reliable in the common case, with honest edge cases. The utility-class soup, the colon-prefixed variants and especially the square-bracket arbitrary values are intrinsic to how Tailwind is written, so on a standard build they are plainly visible in the HTML and detection is straightforward. The reliability dips with the configuration choices noted above — a custom prefix, class obfuscation, or heavy use of @apply that moves utilities into semantic classes — which can disguise the pattern and require you to inspect the stylesheet itself. So "does this site's markup show Tailwind?" is usually answerable with confidence, while "is Tailwind hiding behind renamed classes?" occasionally needs the extra step of reading the compiled CSS. Inspect a few elements, look for the brackets and colon variants, and check the stylesheet if the markup is ambiguous — and your read will be both accurate and honest about its limits.

The workflow

1. Inspect a few elements in the Elements panel and read their class lists.
2. Look for utility soup (flex pt-4 text-sm) and colon variants (md:, hover:).
3. Search for square brackets (w-[327px]) — arbitrary values are near-conclusive.
4. Check the stylesheet for utility definitions, especially if the markup is renamed.
5. Corroborate with a detection tool like Wappalyzer or BuiltWith.

Go deeper

• The design layer: how to find what fonts and colours a website uses.
• The component-first alternative: how to tell if a website uses Bootstrap.
• The whole stack: how to find out what technology a website uses.
• The framework underneath: how to check what JavaScript libraries a website uses.

Want the CSS framework, fonts and full front-end stack identified automatically? Analyse any site with StackOptic — free, no sign-up.