Run a mock round

@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.

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.

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.

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 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 JIT scans the files listed in content and generates only classes it finds as literal strings. Class names built dynamically are invisible to the scanner.

// broken: no utility generated
const cls = `bg-${color}-500`;
// works: full class names present in source
const cls = color === 'red' ? 'bg-red-500' : 'bg-blue-500';

This is the most common Tailwind bug. Fixes: write complete class names in a lookup map or object, add a safelist in the config for values you cannot enumerate, or use inline styles for truly dynamic values.

The content array must include every file type that contains classes, including .vue, .svelte, .php and template files, and broad globs like ./src/**/* are fine. In v4 content is auto-detected, but explicit sources still help with generated files. Keeping class strings static also matters for frameworks that purge unused styles in production.