Why Tailwind CSS suggests changing arbitrary values to standard classes

Overview

We should swap out arbitrary values like w-[100px] for standard utility classes like w-25 in Tailwind CSS. Now that these are supported in newer Tailwind versions, using them helps us stick to a consistent design system and makes the CSS much easier to maintain.

Filling the "Missing" Gaps

Historically, the Tailwind spacing scale had gaps. For example, it jumped from 24 (96px) to 28 (112px). And because values such as 100px is such a common design requirement, developers were forced to use the arbitrary value syntax w-[100px].

In recent versions, Tailwind expanded the default spacing scale to include these missing "integer" steps. Since the Tailwind scale is based on multiples of 0.25rem (4px), the math works out perfectly:

Example: 25 x 4px = 100px

By providing w-25, Tailwind allows you to stay within the "system" rather than breaking out of it and using arbitrary values.

Fractional/Decimal values

Tailwind CSS introduced fractional/decimal values (like 0.5, 25.5, or 5.25) to provide single-pixel precision while maintaining the logic of their design system.

1. The "One Pixel" Problem

As mentioned above, the Tailwind spacing scale is based on the constant: 1 unit = 0.25rem (4px).

Note: Since Tailwind CSS version 4, it is now possible to define your own spacing scale. Refer Tailwind CSS docs - CSS theme variables

Example of customising your CSS spacing scale:

@layer theme {
  :root {
    --spacing: 0.25rem;
  }
}

While increments of 4px work for most layout tasks, they are often too "chunky" for fine-tuned UI details like borders, specific icons, or tight internal padding. By allowing decimals, Tailwind maps specifically to pixel-perfect increments:

• .25 units = 0.25 x 4px = 1px
• .5 units = 0.5 x 4px = 2px
• .75 units = 0.75 x 4px = 3px

If you need a width of exactly 21px, you no longer have to use the "break-out" arbitrary value w-[21px]. You can instead stay within the spacing scale by using:

5.25 x 4px = 21px = w-5.25

2. Elimination of "Arbitrary Value" Friction

The arbitrary value syntax ([...]) was always intended to be an escape hatch for "one-off" values. However, developers found themselves using it constantly for sizes like 10px (w-[10px]) or 102px (w-[102px]).

By supporting decimals, Tailwind makes the spacing scale continuous. This keeps your HTML cleaner and ensures you are still technically using the Tailwind "system" rather than hardcoding raw values.

3. Consistency Across Different Scales

Tailwind's philosophy is that you shouldn't have to switch mental contexts.

• If w-[100px] is a special case for 100px, it feels inconsistent.
• If w-25 is 100px, it follows the mathematical rule of the entire framework.

This is especially useful in recent versions where Tailwind is moving toward a more dynamic, CSS-variable-based system. Having a predictable mathematical scale allows the engine to calculate these values on the fly without needing a massive pre-generated list of classes.

Example Conversion Table

Example showing how non-standard numbers are calculated to exact pixel values:

How it helps with compiling the CSS code to make it more efficient

1. Reduced Parsing Overhead

When the Tailwind engine (especially the JIT engine in v3 or the new engine in v4) scans your files, it has to "parse" every class it finds.

• Arbitrary Values: When the compiler sees w-[100px], it has to run a regex or a parser to extract the value inside the brackets, identify the unit (px), validate that it's a legal CSS value, and then generate the rule.
• Standard Values: When it sees w-25, it uses a highly optimized internal lookup or a simple mathematical transform. It "knows" what 25 is immediately. This makes the scanning phase of the build slightly faster, which is noticeable in very large projects with thousands of files.

Note: Refer Tailwind CSS docs - Detecting Classes

2. Better CSS Deduplication

In a large team, different developers might express the same value in different ways:

• Developer A writes: w-[100px]
• Developer B writes: w-[100.0px]
• Developer C writes: w-[6.25rem]

Even though these result in the exact same width, the Tailwind compiler may treat these as three distinct classes, generating three separate rules in your final CSS file. By sticking to w-25, everyone is forced to use the exact same string, ensuring that the value is only defined once in the final CSS bundle, keeping the file size as small as possible.

3. CSS Variable Optimization (Tailwind v4)

Tailwind v4 is moving toward a CSS-variable-first approach. In this version:

• Standard utilities like w-25 often map directly to a CSS variable like var(--spacing-25).
• This variable is defined once at the :root.
• If you use w-25 in fifty places, the CSS remains very clean and benefits from browser-level optimizations.

Arbitrary values (w-[100px]) often bypass this variable system and generate a hardcoded rule (width: 100px;), which makes the CSS less "thematic" and slightly harder for the browser to optimize compared to repeated variable usage.

4. Gzip and Brotli Compression

Text compression algorithms (like Gzip and Brotli, which serve your CSS over the internet) work by finding repeating patterns.

• The more you use standard classes like w-4, w-8, and w-25, the more "repetitive" your CSS file becomes.
• If your file is full of unique arbitrary values like w-[99px], w-[101px], and w-[102px], the compression algorithm cannot shrink the file as effectively.

By ensuring your CSS code uses a standard scale, you are making your final CSS file much more compressible.

5. IDE and Tooling Efficiency

It also helps out with IDE efficiency:

• IntelliSense: The Tailwind LSP (Language Server Protocol) can pre-cache standard values.
• Known Scale: When you type w-, it can instantly suggest 25 because it's part of the known scale.
• Reduce Lag: Calculating suggestions for arbitrary values is more computationally expensive for your IDE, which can lead to lag in very large HTML or JSX files.

Summary

While w-[100px] isn't "slow" in a way that will break your site or anything major like that, w-25 is the "happy path" for the compiler. It leads to faster builds, smaller CSS files, and better compression, all while keeping your design system strictly enforced.