A class that does nothing is the most common Tailwind bug. Don’t fix it by trying random utilities. Inspect the element and follow a fixed sequence.

1. Check the class in the DOM

Open the Elements panel and read the actual class attribute. Template conditionals, class-merging helpers, and typos produce strings that differ from what you wrote. text-grey-700 looks right and does nothing. Fix the token before looking anywhere else.

2. Search the generated stylesheet

Open the Sources panel or the compiled CSS and search for the selector. Two outcomes:

The rule is missing. Tailwind never saw the complete class. Look for dynamic fragments like bg-${color}-600, which the text scanner can’t understand. Check whether the file lives in an ignored directory, outside the monorepo base path, or in an external library. Add an @source only when you’ve confirmed that’s the cause.

The rule is present. Detection is fine. Now check whether its condition matches. md:* needs the viewport at 48rem or wider. @md:* needs an ancestor with @container. peer-* needs the styled element after the peer in the DOM. dark:* needs the dark condition you configured, whether that’s the system setting or a data-theme attribute.

3. Read the Styles and Computed panels

A crossed-out declaration lost the cascade to another rule. Find the winner. Two utilities setting the same property, like p-2 p-6, are resolved by stylesheet order, not by the order in your HTML. Remove the conflict or make the condition explicit with a variant.

4. Check the layout context

A winning rule can still look broken because the layout assumption is wrong. justify-center needs a Flex or Grid parent. h-full needs a parent with a definite height. z-50 can’t escape a stacking context created by a transformed ancestor. The CSS is correct. The box just can’t use it.

5. Everything else

Only now look at browser support, invalid arbitrary syntax like w-[18 rem], inherited values, CSS variables that resolve to nothing, and stale build output. Restarting the dev server can confirm a watcher problem. It should never be the first diagnosis, because it teaches you nothing.

Keep the evidence

At each step, write down what you found: the source token, the generated selector, the matched condition, the winning computed value, and the layout context. When you ask a colleague for help, that list gets you an answer in one message instead of ten.

Try this: create four controlled failures on purpose, a dynamic class, an inactive variant, a conflicting utility, and a wrong layout context. Diagnose each without guessing and save the DevTools screenshot that settles it.

Debug missing classes