Run a mock round

Tailwind is configured in tailwind.config.js. The content array tells the engine where to scan for class names, and theme customises the design tokens. extend adds to the defaults, while assigning a key directly replaces them.

module.exports = {
  content: ['./src/**/*.{html,js,svelte,tsx}'],
  theme: {
    extend: {
      colors: { brand: { DEFAULT: '#0ea5e9', dark: '#0369a1' } },
      spacing: { 18: '4.5rem' },
      fontFamily: { sans: ['Inter', 'sans-serif'] },
    },
  },
  plugins: [],
};

Prefer extend so utilities like p-4 keep working. You can reference other tokens with theme() in CSS or with functions in the config, add custom screens for breakpoints, and register official plugins such as @tailwindcss/forms and @tailwindcss/typography.

In Tailwind v4 much of this moves into CSS with @theme and @import "tailwindcss", and content is auto-detected, but the token idea is unchanged.

When a design needs a one-off value that is not in the scale, arbitrary value syntax accepts raw CSS inside square brackets: w-[327px], top-[117px], bg-[#1da1f2], grid-cols-[1fr_500px_2fr], where underscores become spaces, and content-['']. You can combine them with variants, for example lg:mt-[3.75rem].

<div class="h-[calc(100vh-4rem)] bg-[url('/hero.jpg')]">...</div>

The JIT engine reads these literals and generates the rule on demand, so there is no performance penalty and they purge correctly as long as they appear as strings in scanned files.

Arbitrary values are an escape hatch, not the default. Repeated magic numbers should be promoted into theme.extend so the design stays consistent and searchable. Arbitrary properties like [mask-type:luminance] and arbitrary variants like [&:nth-child(3)]:mt-4 extend this further, letting you reach almost any CSS without leaving the markup.

Tailwind's performance story is about generation and delivery. The JIT engine produces only the utilities present in scanned files, so production CSS is typically a few kilobytes gzipped versus hundreds of kilobytes for the old full build. Keep content accurate and narrow, because overly broad globs over node_modules slow builds, and avoid constructing class names dynamically since anything not found literally is not generated. Large safelists inflate the output.

The generated stylesheet is minified in production builds. Order layers with @layer so base, components and utilities have predictable specificity, and serve the file compressed over the network. Do not ship the development build; build with NODE_ENV=production so unused variants and dev warnings are removed.

For very large projects, watch build times and avoid thousands of arbitrary values. Bundle the CSS with your framework's build so unused component styles are removed with the components, and inline critical utilities for above-the-fold content.

Tailwind encodes variants as prefixes. Responsive breakpoints are mobile-first: sm, md, lg, xl and 2xl apply at that minimum width and above.

<div class="w-full md:w-1/2 lg:w-1/3">...</div>

That element is full width on small screens, half at md and a third at lg. Dark mode is configured in tailwind.config.js with darkMode: 'media', which follows the operating system, or 'class', which is toggled by adding dark to an ancestor and suits a manual switch. Then dark:bg-gray-900 applies in dark mode.

Variants compose, including with each other, so dark:md:hover:bg-black is valid. Other built-in variants include hover, focus, active, disabled, group-hover, peer-checked, motion-safe, print, and aria- and data-attribute selectors. Custom variants can be registered with addVariant.

Because the JIT engine generates only the classes you actually use, variants cost nothing until referenced.

A plugin is a function passed to plugins in the config. It receives helpers including addUtilities, addComponents, addBase, addVariant, matchUtilities and theme.

const plugin = require('tailwindcss/plugin');

module.exports = {
  plugins: [
    plugin(function ({ addUtilities, addVariant, matchUtilities, theme }) {
      addUtilities({ '.content-auto': { 'content-visibility': 'auto' } });
      addVariant('hocus', ['&:hover', '&:focus']);
      matchUtilities(
        { 'text-shadow': (value) => ({ textShadow: value }) },
        { values: theme('textShadow') },
      );
    }),
  ],
};

addUtilities and addComponents register static classes, matchUtilities generates classes from a value scale, and addVariant creates new modifiers such as hocus. Plugins can be written in JavaScript or, in v4, registered with the @plugin directive.

This is the supported way to encode repeated design decisions such as custom shadows, animation sets or grid systems without scattering @apply. Keep plugins small and documented, and consider a preset to share them across projects.

Utility-first means composing small, single-purpose classes directly in markup instead of writing semantic class names and separate stylesheets. In Tailwind, a class list describes the result without inventing names.

<button class="rounded bg-blue-600 px-4 py-2 text-white hover:bg-blue-700">Save</button>

Benefits: no naming debates, no unused CSS accumulating, styling colocated with markup so deleting a component removes its styles, and design-system constraints on spacing, colour and type that produce visual consistency. Responsive and state variants become trivial through prefixes.

Trade-offs: markup is verbose and long class strings can be hard to scan, though extracting components solves that better than @apply. Teams new to it often overuse @apply and recreate the same bespoke stylesheet problem. The approach works best with a component-driven UI where repetition is encapsulated in components rather than CSS classes.

@apply inlines utility classes into a CSS rule, letting you write component classes while reusing Tailwind's design tokens.

.btn {
  @apply inline-flex items-center rounded px-4 py-2 font-medium;
}
.btn-primary { @apply bg-blue-600 text-white hover:bg-blue-700; }

It is useful for third-party HTML you cannot edit, for base styles on native elements, and for small repeated patterns in a design-system layer. However, overusing it recreates the problem Tailwind avoids: a growing stylesheet of bespoke classes that couples markup to CSS again.

Prefer extracting a framework component in React, Vue or Svelte and keeping utilities in the template, because components can take props, hold state and be tested. Other caveats: @apply resolves at build time so it cannot use classes created dynamically, it cannot reference classes that create circular dependencies in the same file, and important variants need care. Reserve it for @layer components in small doses.