Overview

Tailwind CSS is presented in this repository as a utility-first CSS framework for rapidly building custom user interfaces. The public README and the package README both lead with that product definition, then route readers to the hosted documentation, community discussions, and contribution guidance. In practice, “utility-first” means the primary authoring unit is a class name such as text-3xl, font-bold, or underline, and Tailwind turns the class names it finds in templates and components into generated CSS. The official docs describe the runtime model as fast, flexible, reliable, and zero-runtime because the framework scans source files and writes static CSS instead of shipping a client-side styling runtime.

Sources: README.md, packages/tailwindcss/README.md

This wiki mirrors that split between user-facing documentation and source-level reference. The first pages help you choose an installation path, then the concept pages explain how utility classes, responsive variants, state variants, theme variables, directives, custom styles, and class detection fit together. Later pages become more reference-oriented: they group utility families such as layout, spacing, typography, backgrounds, effects, filters, transforms, animation, interactivity, scrolling, tables, SVG, accessibility, and masks. The final group documents public packages and operational workflows, including the core tailwindcss package API, integration plugins, command-line tooling, upgrade tooling, Node APIs, browser builds, Webpack integration, Oxide, standalone builds, and development/testing practices.

Sources: README.md, packages/tailwindcss/package.json

Purpose and Scope

Use this page as the map for deciding where to start. If you are installing Tailwind CSS into an application, begin with the installation pages rather than the package API reference. The official installation docs expose five first-class routes: Using Vite, Using PostCSS, Tailwind CLI, Framework Guides, and Play CDN. Those routes all share the same underlying idea: import Tailwind in CSS, run a build or runtime integration that scans project files for classes, and include the generated stylesheet in your app. The right route depends on whether your project already has Vite, PostCSS, a framework-specific build system, no build tool, or a browser-only prototype.

Sources: README.md, package.json

If you are extending Tailwind itself or integrating it into tooling, start with the package and API pages. The tailwindcss package publishes the core CSS entry point, TypeScript source entry, CommonJS and ESM build outputs, the plugin helper, default theme compatibility exports, color utilities, and direct CSS files for index.css, preflight.css, theme.css, and utilities.css. That export surface is a useful boundary: most integrations should depend on published entry points rather than reaching into compiler internals, while compatibility pages explain the legacy-style modules that remain intentionally exported.

Sources: packages/tailwindcss/package.json

Relevant Source Files

README.md — Root repository README that defines Tailwind CSS, links to the hosted documentation, and points users to community and contribution channels.
package.json — Root workspace package metadata and scripts for formatting, linting, building, development, tests, integration tests, UI tests, benchmarks, versioning, and playground shortcuts.
packages/tailwindcss/package.json — Public tailwindcss package manifest, including npm metadata, scripts, package exports, published files, and compatibility entry points.
packages/tailwindcss/README.md — Package-level README that repeats the public product positioning and directs package consumers to the hosted documentation and community resources.

Monorepo and Package Map

The root package is private and named @tailwindcss/root, which signals that repository-level commands coordinate packages rather than publishing the root itself. Its scripts show the everyday contributor workflow: pnpm run format applies Prettier, pnpm run lint checks formatting and delegates package linting through Turbo, pnpm run build runs Turbo while excluding playgrounds, and pnpm run test combines Rust tests with Vitest. There are also focused scripts for integration tests, UI tests, test-driven development, benchmarks, package versioning, and launching Vite or Next.js playgrounds. Even in an overview, those script names matter because they show that Tailwind CSS is maintained as a multi-package system with JavaScript/TypeScript, Rust, integration, and playground concerns.

Sources: package.json

The core package is named tailwindcss, is licensed MIT, and is versioned independently from the private root. Its manifest describes the same utility-first framework that the README does, but it adds the published contract that tools consume. The main export maps the package root to index.css for style-aware consumers, to src/index.ts for TypeScript/import development, and to built JavaScript files for CommonJS and ESM publishing. Separate exports expose ./plugin, ./defaultTheme, ./colors, ./lib/util/flattenColorPalette, and individual CSS files. This tells readers that Tailwind’s public surface is both CSS-first and API-aware: applications can import CSS, while tooling and compatibility code can import explicit JavaScript helpers.

Sources: packages/tailwindcss/package.json

Area	What to read next	Why it matters
Application setup	`installation`, `using-vite`, `using-postcss`, `tailwind-cli-installation`, `play-cdn`, `framework-guides`	Choose the build or runtime path that matches your project.
Styling model	`styling-with-utility-classes`, `responsive-design`, `hover-focus-and-other-states`, `dark-mode`, `theme`	Learn the concepts behind class candidates, variants, and CSS-first theme variables.
Utility references	Layout, sizing, spacing, flexbox, grid, typography, backgrounds, borders, effects, filters, transforms, interactivity, and related pages	Look up concrete utility families after you understand the model.
Package APIs	`tailwindcss-package-api`, `configuration-and-plugin-api`, `node-api`, `vite-plugin`, `postcss-plugin`, `cli-reference`	Integrate Tailwind into tools or extend it with supported entry points.
Operations and migration	`upgrade-tool`, `upgrade-guide`, `oxide-engine-and-standalone-builds`, `development-and-testing`	Upgrade projects, understand native engine pieces, and contribute safely.

Installation Paths at a Glance

The official documentation presents installation as a choice among environments, not as a single universal recipe. Vite is treated as a recommended modern build-tool path, PostCSS is the integration point for frameworks and pipelines that already use PostCSS, the Tailwind CLI is the simplest scratch setup and is also available as a standalone executable, Framework Guides provide environment-specific instructions, and Play CDN supports browser-only experimentation. Across those paths, the setup sequence is intentionally similar: install the relevant package or use the browser runtime, add an import for Tailwind CSS, run the build or runtime process that discovers classes, then write markup using utility classes.

Sources: README.md, package.json, packages/tailwindcss/package.json

The root scripts make that installation story credible for contributors because the repository itself exercises several modes. There are scripts for generic builds and development through Turbo, a dedicated integration-test command rooted in the integrations workspace, a UI test command that runs browser-oriented suites for the core package and browser package, and playground shortcuts for Vite and Next.js. As a reader, you do not need those scripts to install Tailwind in an app, but they explain why the wiki separates user setup pages from package references and testing material: each supported installation surface has its own behavior and validation path.

Sources: package.json

Core Primitives

The most important primitive is the utility class. A utility class is a small, composable class name that maps to a CSS declaration or related rule. Official examples use classes such as text-3xl, font-bold, and underline to style markup after the compiled CSS file is included in the page. In the source package, this CSS-first orientation is visible in the style field and exported CSS files, including index.css, preflight.css, theme.css, and utilities.css. Those files represent the public CSS layers that the rest of the documentation breaks down into reset behavior, theme variables, and generated utilities.

Sources: packages/tailwindcss/package.json

The second primitive is the integration boundary. Tailwind can be invoked by a CLI, a PostCSS plugin, a Vite plugin, framework-specific setup, or a browser workflow, but those are entry paths into the same product rather than separate frameworks. The core package export map reinforces this by publishing stable JavaScript and CSS entry points instead of requiring every integration to know internal file structure. When this wiki later describes Vite, PostCSS, Webpack, Node APIs, browser builds, and standalone CLI behavior, treat those pages as adapters around the same core idea: scan sources for class names, compile the matching CSS, and deliver static styles to the application.

Sources: packages/tailwindcss/package.json

The third primitive is compatibility. The manifest exports ./colors, ./defaultTheme, ./plugin, and ./lib/util/flattenColorPalette in addition to the main CSS entry. These names are important because they preserve familiar extension and configuration workflows while Tailwind v4 emphasizes CSS-first customization. In this wiki, compatibility is not a side topic; it connects the colors page, theme page, configuration and plugin API page, and upgrade guide. If you are migrating older code, use those pages together instead of assuming every historical JavaScript configuration pattern has the same role in the current architecture.

Sources: packages/tailwindcss/package.json

Development and Validation Signals

For maintainers and advanced integrators, the root scripts provide the clearest first look at the repository’s validation model. Formatting is centralized through Prettier with organized imports, linting combines formatting checks with Turbo package lint tasks, building runs package builds while excluding playgrounds, and the default test command combines Rust and Vitest test suites. Separate commands cover integration tests, UI tests, benchmark runs, and watch-mode development. This does not replace the dedicated development page, but it gives you enough vocabulary to read it: Turbo coordinates package tasks, Vitest covers JavaScript/TypeScript behavior, Playwright appears in UI testing, and Cargo covers Rust components.

Sources: package.json

The package-level scripts narrow that view to the core tailwindcss package. Its lint script runs TypeScript without emitting output, its build and dev scripts invoke tsup-node with production or development environment settings, and its test:ui script uses Playwright. Those scripts match the package’s role as both a source package and a published artifact: contributors need type-checking and local builds, while consumers receive compiled outputs declared through publishConfig. When debugging a package-level behavior, first decide whether the issue belongs to the root workflow, the core package build, or a specific integration package covered elsewhere in the wiki.

Sources: packages/tailwindcss/package.json

How to Use This Wiki

Start from your task, not from the repository tree. If you want to style an app, read Installation, then Styling with Utility Classes, then the utility reference family that matches the CSS you need. If you want to customize design tokens, go from Theme to Colors and then to Functions and Directives or Adding Custom Styles. If you are wiring Tailwind into a build tool, jump from Installation to the specific Vite, PostCSS, CLI, Webpack, Node API, or browser build page. If you are upgrading, read the Upgrade Guide before the Upgrade Tool reference so you understand the migration goals before running codemods.

Sources: README.md, packages/tailwindcss/README.md, packages/tailwindcss/package.json

For repository work, pair this overview with Development and Testing, then follow the package-specific reference that matches the change. The READMEs intentionally keep the public entry simple: hosted docs for product usage, GitHub Discussions for help and ideas, and contributing docs before pull requests. This wiki adds the missing middle layer by connecting those reader-facing destinations to the source contracts visible in package manifests and scripts. The next best page is usually installation for application developers, tailwindcss-package-api for integration authors, or development-and-testing for contributors preparing a change.

Ask a question...