Alignment and Justification

Purpose and Scope

Alignment and justification utilities control how boxes are distributed along flexbox and grid axes. In Tailwind CSS, these behaviors are expressed as class candidates such as items-center, justify-between, content-start, place-items-center, self-end, and justify-self-stretch. A candidate is the class-like token that the compiler receives from content scanning or from an integration runtime, then resolves into generated CSS when it is part of the active build. This page focuses on the alignment family as a reference for authors who already understand the utility-first model and want to choose the right class for a flex or grid layout.

The important distinction is axis and target. Flex and grid containers use container-level utilities to distribute their children: items-* maps to cross-axis item alignment, justify-* maps to main-axis distribution, content-* maps to multi-line or grid track distribution, and place-* combines align and justify behavior where CSS supports that shorthand. Individual children use self-*, justify-self-*, and place-self-* to override the container default. This separation is why a centered grid item may need place-items-center on the grid container, while a single exception inside that grid may need place-self-start on the child.

Tailwind's implementation model matters because these utilities are not handwritten into every project. The public tailwindcss package exposes the compiler entry point used by integrations, and that compiler imports the candidate compilation machinery that turns class candidates into CSS. The same package exposes CSS entry files such as index.css, preflight.css, theme.css, and utilities.css, so applications can import the framework as CSS while build tools call the compiler API behind the scenes. Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json

Relevant Source Files

• packages/tailwindcss/src/index.ts - Core package entry point for compilation; it imports candidate compilation, design-system construction, directives, variants, theme handling, imports, @apply, and public compile-related types used by integrations.
• packages/tailwindcss/package.json - Declares the tailwindcss package metadata, version, description, CSS entry files, JavaScript exports, compatibility exports, build scripts, and published export map.
• package.json - Monorepo root package file that defines repository-wide scripts for formatting, linting, building, testing, integration tests, UI tests, benchmarks, and playground shortcuts.
• packages/@tailwindcss-browser/src/index.ts - Browser runtime used by Play CDN-style workflows; it creates a compiler in the browser, injects @import "tailwindcss" when needed, observes Tailwind style tags, and builds CSS from discovered classes.
• packages/@tailwindcss-cli/src/index.ts - CLI executable entry point; it dispatches tailwindcss, tailwindcss build, and tailwindcss canonicalize, parses shared flags, and calls the build command.
• packages/@tailwindcss-node/src/index.ts - Node integration barrel and runtime setup; it exports compile, optimization, source-map, normalization, instrumentation, and environment helpers, and registers ESM cache hooks when supported.

Utility Families

Use items-* when you want to align every child of a flex or grid container on the cross axis. Common forms include items-start, items-end, items-center, items-baseline, and items-stretch. In a row-direction flex container, this usually means vertical alignment; in a column-direction flex container, it usually means horizontal alignment. In grid layout, it aligns items within their grid areas. The class belongs on the container because it sets the container's item-alignment policy rather than changing any one child in isolation.

Use justify-* when you want to control main-axis distribution or inline-axis item alignment, depending on the underlying CSS property. For flex containers, classes such as justify-start, justify-end, justify-center, justify-between, justify-around, and justify-evenly are commonly used to distribute children across the main axis. In grid contexts, justification can also determine how grid content or individual grid items align along the inline axis. When debugging a layout, first identify whether the element is the container or the child, then identify whether the axis you care about is the main axis, cross axis, block axis, or inline axis.

Use content-* for groups of lines or tracks, not for a single child. Utilities such as content-start, content-center, content-between, content-around, content-evenly, and content-stretch are most visible when a flex container wraps or when a grid has extra space to distribute between tracks. If changing items-center appears to do nothing in a wrapped layout, the reason may be that the visual gap belongs to line distribution rather than item alignment. In that case, content-* is the family that describes the CSS behavior more directly.

Use place-* utilities when the same intent applies in both alignment dimensions. place-items-* combines item alignment across axes for containers, place-content-* combines content distribution, and place-self-* applies the individual-item shorthand. These utilities are especially convenient in grid layouts, where centering a child in both axes is a common operation. For example, grid place-items-center communicates that the grid is responsible for centering all of its items, while place-self-end communicates that one item opts out of the grid's default placement.

System-to-Code Mapping

The alignment utilities participate in the same compilation pipeline as spacing, typography, color, and other utility families. The core entry point imports compileCandidates, which is the compiler-side concept that turns the class candidates collected from project content into generated CSS. The same file also imports the design-system builder, theme support, variant substitution, CSS parsing, @apply substitution, and import substitution, showing that a class like md:place-items-center is resolved in a pipeline that understands utilities, variants, directives, and theme variables together. Sources: packages/tailwindcss/src/index.ts

The package manifest explains how projects reach that compiler and its CSS assets. The tailwindcss package is described as a utility-first CSS framework for rapidly building custom user interfaces, and its export map exposes the main package, ./plugin, compatibility helpers such as ./colors and ./defaultTheme, and CSS entry points including ./index.css, ./preflight.css, ./theme.css, and ./utilities.css. For alignment classes, the most relevant operational point is that applications can import the CSS entry point while integrations use the JavaScript compiler export to generate only the utilities that appear in the build. Sources: packages/tailwindcss/package.json

Repository scripts show the expected development envelope around these behaviors. The root package defines build, dev, test, test:integrations, test:ui, tdd, and playground commands, with tests spanning Rust crates and Vitest. For a contributor changing alignment generation, that means the utility behavior is not validated by a single package command alone; the repository is organized so package tests, integration tests, UI tests, and playgrounds can all exercise the same public utility surface through different entry points. Sources: package.json

Usage Patterns and Examples

For a basic flex toolbar, start with the container's display and direction, then add alignment. flex items-center justify-between is the common shape for a horizontal bar where children should be vertically centered and the first and last groups should sit at opposite ends. If the bar becomes vertical with flex-col, the meaning of main and cross axes changes, so justify-* affects vertical distribution and items-* affects horizontal alignment. Tailwind does not hide the CSS box-alignment model; it makes each alignment decision a composable class.

<header class="flex items-center justify-between gap-4">
  <a href="/" class="font-semibold">Acme</a>
  <nav class="flex items-center gap-3">
    <a href="/docs">Docs</a>
    <a href="/pricing">Pricing</a>
  </nav>
</header>

For grid layouts, choose between container-wide alignment and per-cell overrides. grid place-items-center is the shortest expression for centering each grid item in both dimensions. If one item needs a different position, keep the grid default on the container and apply place-self-*, self-*, or justify-self-* to that item. This keeps the layout readable: the parent declares the normal rule, and exceptional children declare only their exception. The same responsive and state variant model used elsewhere in Tailwind can prefix these utilities, so a layout can move from items-start to md:items-center without writing a media query by hand.

<section class="grid min-h-64 place-items-center md:place-items-start">
  <div class="place-self-center md:justify-self-end">Featured card</div>
</section>

The official Flexbox & Grid docs for adjacent grid utilities illustrate the same candidate syntax rules that alignment utilities use: breakpoint prefixes like md: apply a utility only at a configured screen size, arbitrary values use square brackets when a fully custom CSS value is required, and custom-property shorthand uses parentheses to wrap a variable in var(...) automatically. Alignment classes normally use a closed set of CSS alignment keywords, so arbitrary values are less common here than with sizing, but the mental model is shared across the utility system.

Runtime Entry Points

Build-tool users usually encounter alignment classes through the core package indirectly. A Vite, PostCSS, Webpack, or Node integration loads CSS, asks Tailwind to compile, and receives generated CSS for candidates that were found. The Node package re-exports compile, optimization, source-map, path normalization, instrumentation, and environment helpers, and it installs ESM cache hooks when the runtime supports them. That matters for alignment utilities in application builds because the integration can reload configuration or imported files while still routing candidate compilation through the same Tailwind core. Sources: packages/@tailwindcss-node/src/index.ts

CLI users reach the same model through an executable command. The CLI entry point parses root flags, supports tailwindcss build, prints help for interactive or --help usage, dispatches canonicalize for candidate-list canonicalization, and hands build flags to the build command. For a developer verifying alignment output from a local stylesheet, the practical workflow is to put alignment classes in content, run a build with an input and output CSS file, and inspect the generated rule set. Sources: packages/@tailwindcss-cli/src/index.ts

Browser and Play CDN-style workflows use a runtime compiler inside the page. The browser package looks for <style type="text/tailwindcss"> blocks, injects @import "tailwindcss" when no import is present, loads virtual Tailwind CSS assets for index, preflight, theme, and utilities, creates a compiler, tracks previously seen classes, and queues builds so concurrent updates do not overlap. In that environment, trying grid place-items-center in markup is still a real Tailwind compilation flow; it is just performed in the browser instead of in a local build tool. Sources: packages/@tailwindcss-browser/src/index.ts

Practical Checklist

When an alignment utility does not behave as expected, inspect the CSS layout context before changing class names. Confirm that the element receiving items-*, justify-*, content-*, or place-items-* is actually a flex or grid container. Confirm whether the visual axis is the flex main axis, flex cross axis, grid inline axis, or grid block axis. Confirm whether the element you are styling is the container or an individual child. Most alignment confusion comes from applying a correct utility to the wrong level of the layout tree.

Next, verify composition. Responsive prefixes such as md: can override earlier alignment choices at larger breakpoints, and state variants can make alignment conditional when used with supported variants. If an integration behaves differently from the browser runtime or CLI, reduce the case to one class candidate and one CSS input, then compare the path that invokes Tailwind: core package import, Node integration, CLI command, or browser compiler. The source entry points documented above are the stable places to continue that investigation before moving into lower-level utility implementation details.