Quick Answer

Tailwind gives you small single-purpose classes you combine in your markup instead of writing CSS. It looks verbose but removes naming decisions and stops your stylesheet growing forever, because you almost never write new CSS.

The problem it is solving

Traditional CSS has two costs that only appear on real projects.

Naming. Every element needs a class name, and inventing meaningful ones for a wrapper inside a card inside a section is genuinely hard. Half of BEM's complexity exists to manage this.

Growth. Stylesheets only grow. Nobody deletes a rule, because nobody can prove nothing uses it. After a year you have 4,000 lines and are afraid to change any of it, so you append instead — which makes it worse.

Tailwind's answer is to stop writing CSS. You compose from pre-existing utility classes, so there is nothing to name and nothing accumulating.

What it looks like

The same card, written both ways. Traditional:

<div class="card">
  <h2 class="card-title">Marks</h2>
</div>

.card { padding: 1rem; border-radius: .5rem;
        background: #fff; box-shadow: 0 1px 3px rgba(0,0,0,.1); }
.card-title { font-size: 1.25rem; font-weight: 600; }

Tailwind:

<div class="p-4 rounded-lg bg-white shadow">
  <h2 class="text-xl font-semibold">Marks</h2>
</div>

Each class does one thing: p-4 is padding, rounded-lg is border radius, text-xl is font size. No separate file, no names invented, and you can see exactly what the element looks like without hunting through a stylesheet.

The numbers come from a fixed scale — p-1 through p-96 map to consistent spacing values. That constraint is a feature: you stop producing 13px in one place and 14px in another.

Responsive and state prefixes

This is where it becomes clearly better than hand-written CSS:

<div class="text-sm md:text-base lg:text-lg">
<div class="flex flex-col md:flex-row">
<button class="bg-blue-500 hover:bg-blue-700">
<div class="bg-white dark:bg-gray-900">

Prefixes apply a utility conditionally. md: is a breakpoint, hover: a state, dark: the colour scheme. Tailwind is mobile-first, so an unprefixed class applies at all sizes and prefixed ones take over as the screen grows.

Compare with hand-written CSS, where a responsive change means finding the right media query, possibly in a different file, and hoping nothing else in that block is affected. Here it is one prefix on the element itself.

The objections, answered honestly

"The markup is unreadable." Fair — a complex element can carry fifteen classes. In practice the trade is that you read one line of markup instead of jumping between two files, and most people find that a net gain after a week. Components help: the repeated string exists once in a React or Astro component, not on every page.

"It is just inline styles again." No. Inline styles cannot do hover, media queries or dark mode, and they impose no design constraints. Tailwind gives you all three and a fixed scale.

"The file will be enormous." The build scans your files and includes only the classes you actually used, so production CSS is typically very small — often smaller than an equivalent hand-written stylesheet.

"I will not learn real CSS." This one is partly true and worth taking seriously. The class names map closely to CSS properties, so you do learn the vocabulary — but you can use Tailwind for months without understanding the cascade or specificity. Learn the fundamentals first; see centering a div for why they still matter.

When not to use it

Tailwind is a poor fit when you are writing a small static page where a stylesheet is simpler and no build step is wanted; when the project needs highly bespoke design that fights the fixed scale; or when you are learning CSS and would be skipping the part you are trying to learn.

It requires a build step, so it is not a drop-in for a plain HTML file. There is a CDN version for prototyping, but it ships every class and is not intended for production.

The strongest case is a component-based application with several people working on it, where naming and stylesheet growth are real daily costs. For a one-page portfolio, plain CSS is completely reasonable.

Frequently Asked Questions

Is Tailwind better than plain CSS? It is better at avoiding naming decisions and unbounded stylesheet growth, which are real problems on larger projects. For small pages, plain CSS is simpler and needs no build step.
Do I need to learn CSS before Tailwind? Yes. The class names map onto CSS properties, so without the underlying knowledge you are memorising vocabulary you cannot reason about. The cascade, specificity and the box model still apply.
Does Tailwind make my CSS file huge? No. The build scans your source and includes only the classes actually used, so production output is usually very small. The large file only exists during development.
How do I avoid repeating long class strings? Extract a component in your framework, so the string exists once. Tailwind also offers @apply for genuinely repeated patterns, though overusing it recreates the stylesheet you were avoiding.
Can I use Tailwind with a plain HTML file? Yes via the CDN build for prototyping, but that ships every class and is not meant for production. A proper setup requires a build step that scans your files.