Question 1

Why does the Tailwind spacing scale skip numbers at the higher end?

Accepted Answer

The scale skips numbers (like jumping from 64 to 72) because humans cannot visually perceive minute differences in spacing at larger scales. While the difference between 4 pixels and 8 pixels is highly noticeable and requires granular control, the visual difference between 256 pixels and 260 pixels is indistinguishable to the human eye. Providing every single 4-pixel increment up to 400 pixels would bloat the framework's file size with hundreds of useless utility classes that provide no tangible design benefit.

Question 2

Can I use absolute pixels instead of rem units in Tailwind?

Accepted Answer

While Tailwind uses rem units by default to ensure maximum accessibility and responsive scaling, you can technically force it to use pixels. This requires modifying the tailwind.config.js file and entirely rewriting the spacing object to map class names directly to pixel string values (e.g., '4': '16px'). However, doing this is highly discouraged by industry experts, as it completely destroys the user's ability to scale the interface using their browser's default accessibility font-size settings.

Question 3

How do I add a custom spacing value that isn't in the default scale?

Accepted Answer

If you frequently need a specific measurement that breaks the 4-pixel grid—for example, exactly 13 pixels—you can extend the default scale in your configuration file. Inside tailwind.config.js, under theme.extend.spacing, you would add a key-value pair like '13px': '13px'. This generates new utility classes like m-13px or p-13px across your entire project. For one-off instances, you should instead use the arbitrary value syntax directly in the HTML, such as mt-[13px].

Question 4

What is the difference between rem and em in this context?

Accepted Answer

Both are relative units, but they relate to different baselines. The rem (root em) unit used by Tailwind's spacing scale is strictly relative to the font size of the root <html> element (usually 16px). This ensures that p-4 is the exact same physical size regardless of where it is placed in the DOM. Conversely, an em unit is relative to the font size of its direct parent element. Tailwind intentionally avoids em for layout spacing because nesting elements with different font sizes would cause the spacing scale to compound and become mathematically unpredictable.

Question 5

How does responsive design affect these spacing utilities?

Accepted Answer

Tailwind's spacing utilities are completely static on their own; p-8 will always equal 2rem regardless of the screen size. To make spacing responsive, you must combine the spacing classes with Tailwind's breakpoint prefixes. By writing p-4 md:p-8 lg:p-12, you instruct the browser to apply 1rem of padding on mobile screens, overwrite it with 2rem of padding when the screen reaches the medium breakpoint (typically 768px), and overwrite it again with 3rem at the large breakpoint (typically 1024px).

Question 6

Is it possible to change the base 1rem = 16px assumption?

Accepted Answer

Yes, but it must be done at the global CSS level, not within Tailwind itself. If you write html { font-size: 20px; } in your global stylesheet, the browser's base definition of 1rem changes from 16px to 20px. Because Tailwind's spacing scale compiles to rem units, the entire mathematical output of the framework will instantly shift. A class like p-4, which outputs 1rem, will now render as 20 pixels instead of 16 pixels. Developers must be extremely cautious when altering the root font size, as it fundamentally alters the 4-pixel grid math the system relies upon.

Tailwind Spacing Calculator

Command Palette