Width, Height, and Logical Sizing

Purpose and Scope

This page is a focused reference for Tailwind CSS sizing utilities: the classes that control element width, height, minimum size, maximum size, logical dimensions, and box sizing. Use it when you are deciding whether an element should take a fixed spacing-scale size, a percentage of its parent, the viewport, a content-based intrinsic size, or a custom value. The official documentation presents these utilities as part of the Sizing and Layout areas, while the repository exposes them through the same compiler and package entry points used by every Tailwind utility. Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json

Sizing classes are ordinary Tailwind class candidates. That matters because they compose with variants, arbitrary values, theme variables, and build pipelines in the same way as color, spacing, typography, and state utilities. The core tailwindcss package exports CSS entry points such as index.css, theme.css, preflight.css, and utilities.css, and its TypeScript entry point imports compiler pieces including compileCandidates, the design system builder, theme handling, and utility creation. A sizing class like max-w-96 is therefore not a special runtime API; it is compiled from a candidate into CSS during the normal Tailwind build. Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json

The most important mental model is that physical dimensions target CSS properties such as width, height, min-width, max-width, min-height, and max-height, while logical dimensions target writing-mode-aware properties. Logical sizing is useful when an interface needs to adapt to vertical writing modes or international layouts because inline size and block size follow the document’s writing direction rather than assuming left-to-right horizontal text. In practice, choose physical utilities for conventional component sizing and logical utilities when your component API should describe layout flow instead of screen axes.

Relevant Source Files

• packages/tailwindcss/src/index.ts — core compiler entry point; imports parsing, theme, design-system, utility, variant, function, and candidate-compilation machinery used when sizing classes are converted into CSS.
• packages/tailwindcss/package.json — declares the tailwindcss package metadata, public exports, CSS entry files, style entry, and package build/test scripts.
• package.json — defines monorepo-level scripts such as build, dev, test, test:integrations, and test:ui, which are the operational entry points for validating generated utilities across packages.
• packages/@tailwindcss-browser/src/index.ts — implements the browser build path used by Play CDN-style workflows; creates a compiler, injects the default Tailwind import when needed, tracks classes, and rebuilds CSS in the page.
• packages/@tailwindcss-cli/src/index.ts — implements the CLI root command, build command dispatch, help flow, and canonicalize command dispatch used when compiling sizing utilities from the command line.
• packages/@tailwindcss-node/src/index.ts — re-exports Node integration APIs for compile, optimization, source maps, instrumentation, and path normalization, and registers ESM cache hooks where supported.

Core Sizing Primitives

Tailwind’s sizing utilities are intentionally scale-oriented. Numeric sizing classes such as max-w-24 and max-h-64 use the spacing scale, so their generated CSS is expressed as a calculation against var(--spacing). This keeps width and height decisions aligned with padding, margin, gap, inset, and other spacing-driven primitives. The official max-width reference shows max-w-<number> compiling to max-width: calc(var(--spacing) * <number>), and the max-height reference uses the same pattern for max-h-<number>. Treat these utilities as semantic access to the project’s spacing rhythm rather than as isolated pixel shortcuts.

Fractions provide another major sizing primitive. A class such as max-h-1/2 or max-w-3/4 represents a percentage of the containing block, and the documentation describes fractional maximum sizes as calc(<fraction> * 100%). This is most useful for nested layouts, constrained media, panels, cards, and viewport-height shells where an element needs to remain proportional to the space around it. Because percentage sizing depends on the parent’s dimensions, debug unexpected results by checking the parent first: the utility can only constrain against a meaningful containing size.

Viewport and intrinsic sizing utilities solve a different problem. The max-width documentation lists viewport-style values such as max-w-screen, max-w-dvw, max-w-lvw, and max-w-svw, and intrinsic values such as max-w-min, max-w-max, and max-w-fit. The max-height documentation mirrors this with max-h-screen, dynamic viewport height and width values, small and large viewport variants, and min-content, max-content, and fit-content forms. These are useful when a component should respect the browser viewport or the natural size of its contents instead of an application spacing scale.

Container-sized maximum width utilities are a common page-layout tool. The official max-width reference includes named container limits from max-w-3xs through max-w-7xl, backed by CSS variables such as var(--container-sm) and var(--container-7xl). Use those utilities for readable text measures, centered page sections, modal widths, and content columns. The related container utility sets width: 100% and applies breakpoint-specific max-width values at documented screen thresholds, making it better suited for sitewide layout wrappers than one-off component constraints.

Box sizing determines how the browser interprets a declared width or height. The official box-sizing reference defines box-border as box-sizing: border-box and box-content as box-sizing: content-box. With border-box sizing, padding and border are included inside the specified size; with content-box sizing, they are added outside it. Tailwind’s preflight base styles make border-box the default for all elements, so most width and height utilities behave as designers expect. Reach for box-content only when you deliberately want the CSS content box to remain the declared size.

Utility Reference

The following compact reference summarizes the sizing families covered by this page. It is intentionally organized by decision rather than by alphabetical class name, because sizing bugs usually come from choosing the wrong sizing model. Use scale-based classes when you want consistent rhythm, fractional classes when the parent should define the size, viewport classes when the browser viewport is the constraint, intrinsic classes when content should drive layout, and arbitrary or custom-property classes when a component-specific value is clearer than extending the theme.

<main class="mx-auto max-w-5xl px-6">
  <section class="grid gap-6 md:grid-cols-2">
    <article class="max-w-prose">
      <h1 class="text-3xl font-bold">Sizing example</h1>
      <p class="max-w-2xl">Content can be constrained independently from the page shell.</p>
    </article>
    <aside class="max-h-dvh overflow-auto">
      <div class="box-border max-h-96 p-6">Scrollable supporting content</div>
    </aside>
  </section>
</main>

System-to-Code Mapping

The public package boundary is the first implementation detail to understand. packages/tailwindcss/package.json identifies tailwindcss as a utility-first CSS framework package and exposes both JavaScript and CSS entry points. The package root maps to the TypeScript source in development and to built library files for publishing, while ./index.css, ./theme.css, ./preflight.css, and ./utilities.css are exported as CSS assets. That export shape is why sizing utilities can be consumed through direct CSS imports, framework integrations, the CLI, and browser-oriented builds without each integration reimplementing the utility catalog. Sources: packages/tailwindcss/package.json

The compiler entry point in packages/tailwindcss/src/index.ts coordinates parsing CSS, resolving imports, applying compatibility hooks, substituting CSS functions, building the design system, handling theme directives, compiling candidates, and serializing the resulting AST. For sizing utilities, the relevant concept is not a separate sizing service but the shared candidate pipeline. A class name discovered in source is treated as a candidate; the compiler resolves it against the design system and utilities, applies variants as needed, and emits CSS. This shared path is what lets md:max-w-3xl, hover:max-h-96, and arbitrary values participate in normal Tailwind composition. Sources: packages/tailwindcss/src/index.ts

The browser package demonstrates the same model in a different runtime. packages/@tailwindcss-browser/src/index.ts creates a compiler with tailwindcss.compile, reads <style type="text/tailwindcss"> blocks, and injects @import "tailwindcss" when the user has not provided an import. It also maintains a set of classes already seen on the page so it can pass only new classes to later builds. In a Play CDN-style workflow, adding a class such as max-w-80 or box-border to markup is still a compiler action; it is just scheduled inside the browser instead of during a local build step. Sources: packages/@tailwindcss-browser/src/index.ts

The CLI and Node packages provide operational paths for the same sizing output. The CLI entry point parses root flags, dispatches tailwindcss build, offers help output, and includes a canonicalize command for candidate lists. The Node package re-exports compile, optimization, source-map, instrumentation, and path-normalization modules, then configures ESM cache behavior for supported Node runtimes. If you are validating a sizing regression, remember that these entry points should agree on generated CSS because they rely on the same core compiler package rather than separate sizing implementations. Sources: packages/@tailwindcss-cli/src/index.ts, packages/@tailwindcss-node/src/index.ts

Execution Flow

A typical local build starts with project CSS importing Tailwind, for example with @import "tailwindcss". The package export map makes that CSS entry available, and the compiler parses the stylesheet, resolves imports, evaluates directives and functions, builds the design system, and compiles the candidates discovered by the integration. When the candidate list includes sizing classes, those classes are emitted as CSS declarations in the utilities layer. Variants such as breakpoints or state prefixes are applied by the shared variant machinery, so md:max-w-4xl means the sizing rule is wrapped or transformed according to the breakpoint variant rather than implemented by a separate max-width feature. Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json

In a command-line setup, the user-facing task is to invoke the build command with an input CSS file and output target. The CLI source defines usage as tailwindcss [--input input.css] [--output output.css] [--watch] [options…] and also supports the explicit tailwindcss build form. The sizing utilities do not require CLI-specific configuration; the important checks are that the input imports Tailwind, the content being scanned contains the classes you expect, and the generated output includes the corresponding max-width, max-height, width, height, min-size, or box-sizing declarations. Sources: packages/@tailwindcss-cli/src/index.ts

tailwindcss --input ./src/input.css --output ./dist/output.css --watch
tailwindcss build --input ./src/input.css --output ./dist/output.css

In the browser runtime, the flow is intentionally more dynamic. The package reads Tailwind CSS style tags, loads virtual copies of Tailwind’s CSS assets for supported imports, compiles the stylesheet, observes stylesheet changes, and injects compiled CSS into a generated <style> element. That makes browser experimentation convenient for sizing because you can adjust classes directly in markup and let the runtime rebuild. The tradeoff is that the browser build supports a constrained import environment; the source throws when an unsupported import is requested, so production applications should prefer a normal build-tool, CLI, or framework integration. Sources: packages/@tailwindcss-browser/src/index.ts

Practical Guidance and Next Steps

When choosing a width or height utility, start from the constraint you actually want to express. Use w-*, h-*, min-*, and max-* families for direct dimensions; use max constraints when content can be smaller but must not exceed a limit; use min constraints when content may grow but should not collapse; and use box-border when declared dimensions should include padding and border. Prefer documented scale, fraction, container, viewport, and intrinsic utilities before arbitrary values, because scale-based utilities make components easier to audit and keep layout decisions aligned with the rest of the design system.

For responsive sizing, apply breakpoint variants rather than duplicating component markup. A common pattern is a full-width element on small screens that gains a readable maximum width on larger screens, such as w-full max-w-md md:max-w-2xl lg:max-w-4xl. For scrollable regions, pair maximum height utilities with overflow utilities, for example max-h-dvh overflow-auto, so the layout constraint and overflow behavior are explicit. If the size depends on a product-specific token, prefer the custom-property form such as max-w-(--panel-width) so the utility remains readable while the value stays configurable.

Next, read the pages on Theme, Spacing, Responsive Design, Styling with Utility Classes, and the tailwindcss Package API. Theme explains the variables that power scale-based sizing and container sizes; Spacing covers the shared scale behind numeric size utilities; Responsive Design explains breakpoint variants; Styling with Utility Classes describes candidates and composition; and the package API page documents the compiler entry points used by CLI, browser, Node, Vite, PostCSS, and other integrations.