Build and Production

This section documents Tailwind CSS v4.x — the CSS-first configuration line, whose v4.0 release shipped in January 2025 — as published at the official Tailwind CSS documentation, which is the reference these pages are written and verified against. No specific patch version is pinned.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, since Tailwind iterates quickly.

This section’s bibliography lists the reference material consulted while preparing these pages.

Tailwind v4 has no separate "purge" phase: the engine reads your source files, works out which utility classes you actually use, and emits exactly the CSS for those — and nothing else — in one stylesheet.

How the build works end to end

The pipeline is: scan the source files → generate only the utilities that appear → write one small stylesheet.

  1. Your CSS entry point is a single import. Everything else — the reset, the theme variables, every utility and variant — is pulled in and generated by that line. See Using PostCSS and the v4 release notes.

    /* app.css -- the whole Tailwind entry point in v4 */
@import "tailwindcss";

  2. The engine automatically discovers template files to scan, starting from the current directory, honouring your .gitignore, and skipping binary and generated files. It scans them as plain text, extracts candidate class names, and generates CSS only for the ones it finds. Nothing else ends up in the output, so there is nothing to strip afterwards. See Detecting classes in source files.

  3. When automatic detection is not enough — a component library in node_modules, a path that is gitignored, classes that only exist in a database — you register extra sources explicitly in CSS. There is no content array and no tailwind.config.js required in v4.

    @import "tailwindcss";

/* pull in classes from a dependency that ships pre-built markup */
@source "../node_modules/@acme/ui/dist";

/* opt a path back out of scanning */
@source not "../src/legacy";

/* keep specific classes that never appear literally in source */
@source inline("bg-red-500 bg-green-500 bg-blue-500");

Because the CSS is generated on demand rather than generated in full and then trimmed, v4 needs no purge option, no content glob, and no separate PurgeCSS step. Removing a component from your templates removes its utilities from the next build automatically.

Minification

The generated stylesheet is already minimal in rules; --minify also strips whitespace and comments for the smallest possible file. Add it to a standalone CLI build:

# one-off production build with the npm CLI
npx @tailwindcss/cli -i src/app.css -o dist/app.css --minify

# or watch during development (no --minify)
npx @tailwindcss/cli -i src/app.css -o dist/app.css --watch

When Tailwind runs inside a bundler, the framework’s own production build minifies the CSS for you — for example vite build (or npm run build in a Vite, Next.js, or SvelteKit project) emits minified, hashed assets with no extra flags. A real application’s Tailwind stylesheet is typically well under 10 kB compressed, and it grows with the number of distinct utilities used, not with the size of the codebase.

The three integration shapes

Pick whichever matches your toolchain; the CSS output is the same.

  1. Bundler plugin — @tailwindcss/vite, the fastest path for any Vite-based project (React, Vue, Svelte, SolidJS, Astro, SvelteKit).

    // vite.config.js
import { defineConfig } from "vite";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [tailwindcss()],
});

  2. PostCSS plugin — @tailwindcss/postcss, for build setups that already run PostCSS (Next.js, Angular, webpack, Parcel). See Using PostCSS.

    // postcss.config.mjs
export default {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

  3. Standalone CLI — a single self-contained executable with no Node.js required, ideal for Ruby on Rails, Laravel, Go, and Phoenix projects that would otherwise not need a JavaScript toolchain.

    # download the binary for your platform, then run it like the npm CLI
curl -sLO https://github.com/tailwindlabs/tailwindcss/releases/latest/download/tailwindcss-macos-arm64
chmod +x tailwindcss-macos-arm64
mv tailwindcss-macos-arm64 tailwindcss

./tailwindcss -i app/assets/stylesheets/app.css -o public/assets/app.css --minify

For framework-specific wiring — where the entry CSS lives, which command to run — follow the official framework guides.

Play CDN and CI

The Play CDN (<script src="https://unpkg.com/@tailwindcss/browser@4"></script>) compiles Tailwind in the browser at page load. It is for prototyping and reduced test cases only — never production, where it costs a full compile on every visit and ships the entire engine to the client.

In CI, run the same build command you run locally — npx @tailwindcss/cli …​ --minify, or your framework’s build script. Given the same source files and the same Tailwind version, the output stylesheet is a deterministic artifact: byte-for-byte reproducible, safe to cache between runs, and meaningful to diff in a pull request. Treat it like any other compiled asset.

See also Build-Time Performance Optimization for the general CSS delivery picture — minification, compression, hashing, and critical CSS — into which the Tailwind output slots unchanged, and Upgrading from v3 to v4 if you are moving a v3 tailwind.config.js project onto this pipeline.