px vs. em vs. rem: CSS Units Explained

px, em and rem are three of the most common CSS units, and choosing between them affects much more than the apparent size of text.

They influence how typography scales, how components respond to their context, how spacing behaves when font sizes change and how easily a design adapts to different screens and user preferences.

The basic distinction is simple:

• px represents a CSS pixel and behaves as an absolute CSS length;
• em is relative to a font size in the current element’s context;
• rem is relative to the font size of the document’s root element.

But that short definition hides several important details.

For example, 1em does not always mean the same number of pixels. Nested elements can compound when their font-size is expressed in em. A rem value avoids that compounding because it keeps referring to the root. And a CSS pixel is not necessarily one physical pixel on a modern high-density display.

These distinctions become especially important when building WordPress themes, custom blocks, administration interfaces and responsive layouts. A site can look perfectly balanced at one font size while becoming cramped or disproportionate when its sizing relationships have been defined poorly.

This guide explains how px, em and rem actually work, how browsers calculate them, when each unit is useful, which mistakes commonly appear in responsive interfaces and how to choose a practical unit strategy for WordPress and modern web development.

Absolute and relative CSS lengths

CSS supports many different length units. The MDN CSS length reference separates them into absolute and relative lengths.

Absolute CSS length units include:

• px;
• cm;
• mm;
• in;
• pt;
• pc;
• Q.

Relative units include font-relative units such as:

• em;
• rem;
• ch;
• ex;
• lh;
• rlh.

CSS also provides viewport-relative units such as vw, vh, svh, lvh and dvh. These solve different sizing problems because their reference is the viewport rather than typography.

The MDN guide to CSS values and units provides a broader introduction to how these measurement systems interact.

The important distinction for px, em and rem is the reference used to calculate the final length.

With pixels:

.example {
    padding: 20px;
}

the specified length is 20 CSS pixels.

With em:

.example {
    padding: 1.25em;
}

the final padding depends on the element’s computed font size.

With rem:

.example {
    padding: 1.25rem;
}

the final value depends on the root element’s font size.

That difference determines how each value reacts when typography or surrounding context changes.

CSS pixels are not necessarily physical device pixels

A common misunderstanding is that one CSS pixel always corresponds to one illuminated hardware pixel on the display.

Modern browsers do not work that way.

CSS defines relationships between absolute units, including 1in = 96px. On high-density displays, one CSS pixel may correspond to multiple physical device pixels. The browser and device handle that mapping.

So when you write:

.icon {
    width: 24px;
    height: 24px;
}

you are asking for a 24 CSS-pixel box, not manually controlling 24 physical screen pixels.

This distinction matters when thinking about responsive interfaces. Screen density and layout size are different concerns. Responsive CSS should describe how the interface uses the available space rather than attempting to map directly to the display’s hardware pixels.

How px works in CSS

px is the easiest of the three units to reason about because its specified value does not depend on the font size of a parent or root element.

For example:

.card {
    border: 1px solid #dcdcde;
    border-radius: 8px;
    padding: 24px;
}

.card__title {
    font-size: 24px;
}

The browser does not need to inspect the card’s parent font size to determine those pixel lengths.

This predictability is one reason pixels remain useful.

Where pixels work well

Pixels can be appropriate when you want precise, stable values for details such as:

• thin borders;
• small icon dimensions;
• focus outlines;
• some shadows;
• fine offsets;
• specific graphical details.

For example:

.input {
    border: 1px solid #c3c4c7;
}

.input:focus-visible {
    outline: 2px solid currentColor;
    outline-offset: 2px;
}

.icon {
    width: 20px;
    height: 20px;
}

There is nothing inherently wrong with using px. Modern CSS is not improved by replacing every pixel value mechanically with a relative unit.

The better question is whether a dimension should remain independent from the surrounding typography.

Why pixels can be less flexible for typography

Typography often benefits from being connected to the user’s font-size preferences.

The MDN documentation for font-size explains the different absolute, relative and length-based ways font sizes can be defined.

Instead of building an entire typographic system from unrelated fixed values such as:

body {
    font-size: 16px;
}

h1 {
    font-size: 48px;
}

h2 {
    font-size: 36px;
}

h3 {
    font-size: 28px;
}

a relative scale can preserve a clearer relationship between body text and headings.

This becomes particularly relevant in complex interfaces. Our guide to Making the WordPress Admin More Readable explores how typography, spacing and interface density affect usability inside WordPress.

Do not confuse this with browser zoom. Modern browsers can zoom pages containing pixel-based dimensions. The important difference is how the stylesheet itself responds to typography relationships and user font-size preferences.

How em works and why it can compound

The em unit is font-relative.

Its exact reference depends on where it is used.

For most properties, 1em corresponds to the element’s computed font-size.

For example:

.button {
    font-size: 20px;
    padding: 0.5em 1em;
}

Because the button’s font size is 20px, its padding resolves conceptually to 10px vertically and 20px horizontally.

This is extremely useful for component-level spacing.

If the button becomes larger:

.button--large {
    font-size: 24px;
}

the em-based padding grows with it. The component keeps approximately the same internal proportions without requiring another padding declaration.

This principle is useful well beyond buttons. Badges, navigation controls, form elements and icons can all use em when their dimensions should follow the component’s typography.

em behaves differently on font-size itself

When em is used as the value of font-size, the browser cannot calculate it from the element’s new font size because that would create a circular dependency.

Instead, the value is calculated from the inherited font size.

Suppose the parent uses:

.parent {
    font-size: 20px;
}

.child {
    font-size: 1.5em;
}

The child’s computed font size becomes 30px.

This contextual behavior is what makes em powerful, but it is also what makes it easier to misuse.

The MDN text and font styling guide provides additional background on font inheritance and relative sizing.

The em compounding problem

Consider nested elements:

.navigation {
    font-size: 1.2em;
}

.navigation ul {
    font-size: 1.2em;
}

.navigation ul ul {
    font-size: 1.2em;
}

Assume the inherited base size is 16px.

The first level becomes 19.2px. The next level is relative to that computed value and becomes 23.04px. Another nested level becomes approximately 27.65px.

The values compound because each nested element inherits a font size that has already been scaled.

Compounding is not a browser bug. It is the intended consequence of using a unit whose reference changes with the surrounding font context.

This can become especially difficult to control in large interfaces containing nested menus and submenus. For a practical WordPress example of how interface dimensions and responsive behavior interact, see WordPress Admin Menu Responsive Breakpoints, Explained.

How rem solves the inheritance problem

rem means root em.

Instead of following the immediate font context, it refers to the font size of the root element, normally <html>.

Suppose the document uses:

html {
    font-size: 16px;
}

Then 0.5rem resolves to 8px, 1rem to 16px, 1.5rem to 24px and 2rem to 32px.

Now consider nested elements:

.navigation {
    font-size: 1.2rem;
}

.navigation ul {
    font-size: 1.2rem;
}

.navigation ul ul {
    font-size: 1.2rem;
}

Every declaration refers to the same root size.

If the root is 16px, each one resolves to 19.2px. The nesting depth does not multiply the font size.

Do not assume that 1rem always equals 16px

This is one of the most important rules to remember.

Many browsers commonly use 16px as their default font size, but rem does not mean 16px.

It means the computed font size of the root element.

If you write:

html {
    font-size: 20px;
}

then 1rem becomes 20px and 2rem becomes 40px.

If the root size changes, all rem-based dimensions respond to it.

A practical root strategy

A common foundation is simply:

html {
    font-size: 100%;
}

or to leave the root font size unset and allow the browser’s normal default and user preferences to participate.

Then a typographic system can use relative values:

body {
    font-size: 1rem;
}

h1 {
    font-size: 3rem;
}

h2 {
    font-size: 2.25rem;
}

h3 {
    font-size: 1.75rem;
}

small {
    font-size: 0.875rem;
}

This is generally easier to reason about than deeply nested em-based typography.

When the typeface itself also changes, sizing is only part of the problem. Different fonts have different metrics, which can alter line wrapping and geometry even when their CSS font-size is identical. See Why Web Fonts Cause Layout Shift and How to Avoid It for the performance consequences of those metric differences.

px vs. em vs. rem in real components

The differences become clearer when the units are used in actual components rather than isolated calculations.

A button sized entirely in pixels

.button {
    font-size: 16px;
    padding: 10px 18px;
    border-radius: 6px;
}

The values are straightforward and predictable.

But creating a larger version may require changing several properties:

.button--large {
    font-size: 20px;
    padding: 13px 22px;
    border-radius: 8px;
}

A button using rem

.button {
    font-size: 1rem;
    padding: 0.625rem 1.125rem;
    border-radius: 0.375rem;
}

All dimensions are tied to the document root.

This creates consistent global scaling, but changing only the button’s local font size does not automatically change its rem-based padding.

A button using rem and em together

A more contextual component can use rem for typography and em for dimensions that should follow that typography:

.button {
    font-size: 1rem;
    padding: 0.625em 1.125em;
    border-radius: 0.375em;
}

.button--large {
    font-size: 1.25rem;
}

Now the large variant increases its font size and the padding and radius scale with it automatically.

This illustrates an important principle: you do not need to choose one CSS unit for the entire website.

Different units describe different relationships.

Think in relationships rather than conversions

Instead of asking whether every 16px value should become 1rem, ask what the dimension should be relative to.

• If it should follow the document’s base typography, rem is often useful.
• If it should follow the component’s own typography, em is often useful.
• If a precise CSS dimension is intentional, px may be appropriate.
• If it should follow the viewport, consider viewport units.
• If it should follow the containing block, percentages or container-relative techniques may be more appropriate.

This same principle matters when building touch-oriented interfaces. A control that looks adequate on desktop can become difficult to use on a smaller touchscreen when its dimensions have been chosen purely for visual compactness. Making the WordPress Admin Touch-Friendly examines that problem specifically in the WordPress backend.

Typography, spacing and responsive design

One of the strongest uses for rem is building a coherent typographic and spacing scale.

For example:

:root {
    --space-xs: 0.5rem;
    --space-sm: 0.75rem;
    --space-md: 1rem;
    --space-lg: 1.5rem;
    --space-xl: 2rem;

    --text-sm: 0.875rem;
    --text-base: 1rem;
    --text-lg: 1.25rem;
    --text-xl: 1.75rem;
    --text-2xl: 2.5rem;
}

Components can consume those values consistently:

.card {
    padding: var(--space-lg);
}

.card__title {
    margin-bottom: var(--space-sm);
    font-size: var(--text-xl);
}

.card__text {
    font-size: var(--text-base);
}

This creates a centralized scale without forcing every value to be identical.

CSS custom properties themselves are documented in the MDN guide to using CSS custom properties. Combining variables with relative units is particularly useful when building reusable design systems.

Relative units do not automatically make a site responsive

A common misconception is that using rem automatically makes a layout responsive.

It does not.

This declaration:

.container {
    width: 75rem;
}

can still overflow a narrow viewport.

Responsive layouts depend on relationships between dimensions, available space and layout algorithms.

A more resilient container might use:

.container {
    width: min(100% - 2rem, 75rem);
    margin-inline: auto;
}

Here the maximum width is root-relative while the container can still shrink to fit the available space.

The min() function, together with max() and clamp(), allows modern CSS to combine flexible calculations with explicit limits.

Fluid typography can combine rem with viewport units

For example:

h1 {
    font-size: clamp(
        2rem,
        1.5rem + 2vw,
        4rem
    );
}

This allows the heading to grow fluidly while keeping a defined minimum and maximum.

The relative minimum and maximum preserve a connection to root typography, while the middle expression introduces viewport-based scaling.

Media queries remain another important part of responsive CSS. The MDN guide to using media queries explains how styles can respond to viewport and device characteristics.

In WordPress admin interfaces, breakpoints can have additional consequences because navigation itself changes structure as the viewport becomes narrower. That behavior is covered in WordPress Admin Menu Responsive Breakpoints, Explained.

When customizing the dimensions of that menu, the relationship between width, text size and spacing becomes equally important. See How to Widen the WordPress Admin Menu and How to Adjust WordPress Admin Menu Spacing for practical examples.

Accessibility and user font preferences

CSS unit choice can affect how well an interface adapts to users who need larger text.

Relative sizing makes it easier to preserve meaningful relationships between typography and the dimensions around it.

The WCAG guidance on resizing text requires text to remain usable when enlarged, while the WCAG guidance on text spacing highlights the importance of interfaces continuing to work when users modify typographic spacing.

This is one reason a root-relative typography system is often preferable to treating every text size as an isolated graphical measurement.

Avoid resetting the root merely to simplify arithmetic

A frequently seen technique is:

html {
    font-size: 62.5%;
}

If the browser base is 16px, that commonly makes 1rem equal to 10px.

Developers then write values such as 1.6rem and 2.4rem because the mental conversion to 16px and 24px is convenient.

The technique works mathematically, but developer arithmetic is not the only consideration when establishing the root typography of a document.

Modern CSS variables, design tokens, calc() and browser developer tools make manual conversion far less important than it once was.

A simpler foundation is often:

html {
    font-size: 100%;
}

with meaningful relative values built on top.

Do not confuse browser zoom with default font-size preferences

Browser zoom and a user’s configured default font size are related accessibility mechanisms, but they are not identical.

Browser zoom generally scales the rendered page, including pixel-based dimensions.

A relative font-size system additionally allows typography and dimensions tied to it to respond naturally to the font-size reference used by the browser.

So the simplistic claim that pixel-sized text cannot be zoomed is not an accurate description of modern browser behavior.

The more useful accessibility question is whether the interface remains usable when users enlarge text, modify text spacing or change their preferred text size.

For backend WordPress interfaces, this problem extends beyond font size alone. Making the WordPress Admin More Readable covers font size, line height, spacing, contrast and information density as a combined usability problem.

Common px, em and rem mistakes

Most unit problems come from choosing a unit without understanding its reference.

Mistake 1: assuming 1rem always equals 16px

It often does under common default settings, but it is not guaranteed.

rem means root-relative, not “divide pixels by 16.”

Mistake 2: using em everywhere

A completely em-based interface can become difficult to reason about because values change with their local font context.

.card {
    font-size: 1.1em;
}

.card__body {
    font-size: 1.1em;
}

.card__note {
    font-size: 1.1em;
}

Each nested level can scale from the already-scaled parent.

If global consistency is the objective, rem is usually easier to manage.

Mistake 3: replacing every px value with rem

A declaration such as border: 0.0625rem solid; is not automatically better than border: 1px solid;.

The first introduces a root-font relationship that may provide no practical benefit for that border.

Use relative units where the relationship provides value.

Mistake 4: using rem when local scaling is desired

Consider an icon attached to a button:

.button__icon {
    width: 1rem;
    height: 1rem;
}

If the button’s font size changes locally, the icon remains tied to the root.

If the icon should scale with the button instead:

.button__icon {
    width: 1em;
    height: 1em;
}

may express the intended relationship more accurately.

Mistake 5: using fixed units to solve flexible layout problems

A layout such as:

.content {
    width: 960px;
}

has a different problem from typography.

Changing it mechanically to 60rem does not make it fluid. The width is still fixed relative to a reference.

A more responsive approach could be:

.content {
    width: min(100% - 2rem, 60rem);
    margin-inline: auto;
}

Mistake 6: changing units without testing the surrounding interface

Changing a global font scale can affect much more than text.

It can change:

• line wrapping;
• navigation width;
• button dimensions;
• table density;
• form heights;
• modal dimensions;
• dashboard layouts;
• breakpoint behavior.

This is especially visible in the WordPress backend. If your changes affect navigation dimensions, compare them with How to Widen the WordPress Admin Menu before assuming that increasing text size alone will produce a better interface.

How to use px, em and rem in WordPress

WordPress does not change the CSS rules for these units. The browser calculates px, em and rem exactly as it does on any other website.

What WordPress changes is the number of styling contexts you may encounter.

A WordPress project can include:

• theme styles;
• block styles;
• Global Styles;
• plugin styles;
• the Block Editor;
• the Site Editor;
• administration screens;
• the login screen.

Each context may have its own typography and inheritance chain.

Theme typography and theme.json

For frontend theme typography, rem is often useful for maintaining a predictable site-wide scale.

Modern WordPress themes can also define typography presets through theme.json. The official WordPress Theme Handbook typography documentation explains how themes can register font sizes and other typography settings.

For example:

{
    "settings": {
        "typography": {
            "fontSizes": [
                {
                    "slug": "small",
                    "size": "0.875rem",
                    "name": "Small"
                },
                {
                    "slug": "medium",
                    "size": "1rem",
                    "name": "Medium"
                },
                {
                    "slug": "large",
                    "size": "2rem",
                    "name": "Large"
                }
            ]
        }
    }
}

This allows the design system to expose meaningful presets rather than requiring editors to think about CSS units directly.

The broader relationship between CSS, theme.json, editor styles and the WordPress editing canvas is covered in WordPress Block Editor CSS, Explained.

If you are working with block themes rather than classic themes, WordPress Full Site Editing and Block Widgets, Explained provides additional context for how global styles, templates and blocks fit together.

Frontend CSS should still be loaded correctly

Choosing good units does not help if stylesheets are loaded carelessly.

WordPress themes and plugins should use the platform’s asset-loading APIs rather than inserting arbitrary stylesheet tags throughout templates. wp_enqueue_scripts Explained covers how WordPress registers and loads CSS and JavaScript resources.

This becomes important in larger projects where several themes, plugins and blocks may contribute CSS simultaneously.

WordPress admin interfaces

The administration area has its own typography and styles.

If you customize backend font sizes, relative units can help create a scalable system, but remember that em values inherit from the specific admin component in which they appear.

For backend typography specifically, see How to Change the WordPress Admin Font.

Typography is only one part of admin readability. If a backend feels cramped, changing font size without reconsidering padding can make the problem worse. How to Adjust WordPress Admin Menu Spacing covers that relationship for the main navigation.

Likewise, a wider navigation may be necessary when labels become larger or longer. That case is covered in How to Widen the WordPress Admin Menu.

Web fonts add another sizing variable

A CSS unit determines the requested size, but the selected font determines the actual glyph metrics within that size.

Two fonts rendered at 1rem can have noticeably different x-heights, character widths and perceived sizes.

For the hosting side of that decision, see Self-Hosted Fonts vs. Google Fonts in WordPress.

If Google Fonts are being moved under your own control, Self-hosting Google Fonts in WordPress covers the implementation and delivery considerations.

And if fonts change geometry while loading, Why Web Fonts Cause Layout Shift and How to Avoid It explains why a technically correct rem scale does not by itself prevent layout instability.

A practical unit strategy for modern CSS

There is no requirement to standardize an entire project on one unit.

A practical system can use each unit according to the relationship it needs to express.

Use rem for global typography and spacing scales

Good candidates include body text, headings, section spacing, global gaps, maximum content widths and design-system tokens.

:root {
    --text-sm: 0.875rem;
    --text-base: 1rem;
    --text-lg: 1.25rem;
    --text-xl: 2rem;

    --space-sm: 0.75rem;
    --space-md: 1rem;
    --space-lg: 2rem;
}

Use em for component-relative dimensions

em is especially useful when a component should scale with its own typography.

Examples include button padding, icons beside text, badges, component-specific gaps and some border radii.

.badge {
    font-size: 0.875rem;
    padding: 0.25em 0.65em;
    border-radius: 999px;
}

The text size belongs to the global scale, while the padding belongs to the badge itself.

Use px where a fixed CSS dimension is intentional

Good candidates can include one-pixel borders, small graphical details, certain icon assets and precise outlines or offsets.

.field {
    border: 1px solid currentColor;
}

.field:focus-visible {
    outline: 2px solid currentColor;
    outline-offset: 2px;
}

The important part is not avoiding pixels. It is knowing why the value should be pixel-based.

Use other units when they describe the relationship better

px, em and rem are not the entire CSS sizing system.

Depending on the problem, consider:

• % for proportions relative to a containing block;
• ch for text-oriented measures;
• vw and vh for viewport relationships;
• dvh for dynamic viewport height behavior;
• fr for distributing Grid tracks;
• lh for lengths related to line height.

The MDN CSS numeric data types reference documents the broader family of numeric and relative length values available in CSS.

For layout specifically, the MDN CSS Grid guide explains why units such as fr solve a different problem from font-relative lengths.

Performance, maintainability and choosing a consistent system

The performance difference between writing 16px and 1rem is not the reason to choose one over the other.

The meaningful differences are architectural.

A coherent unit strategy can make CSS easier to maintain because developers can understand the intended relationship from the declaration itself.

For example:

:root {
    --text-base: 1rem;
    --space-section: 4rem;
}

.button {
    padding: 0.65em 1.1em;
    border: 1px solid currentColor;
}

Here the code communicates three different intentions:

• global text follows the root;
• global section spacing follows the root;
• button spacing follows the button’s typography;
• the border remains a precise CSS-pixel dimension.

This is more meaningful than converting everything into one unit for stylistic consistency.

Do not let a design system create unnecessary CSS complexity

A design system should reduce arbitrary values, not generate hundreds of variables that nobody understands.

Likewise, optimizing CSS should focus on the amount and relevance of the stylesheet rather than obsessing over whether individual declarations use two extra characters.

If a WordPress site is shipping too much frontend code, Reducing WordPress Front-End Requests covers the wider request problem.

For block-based websites, WordPress Block Editor CSS, Explained also explains why editor styles, frontend styles and block-specific styles should not simply be merged into one indiscriminate stylesheet.

The goal is a CSS architecture where units express relationships, styles are loaded in the correct context and responsive behavior remains understandable.

Quick px vs. em vs. rem reference

Unit	Relative to	Typical use	Main consideration
px	CSS reference pixel	Borders, precise dimensions, graphical details	Does not inherit a font-size relationship
em	Element font context	Component-relative spacing and sizing	Can compound when used for nested font sizes
rem	Root element font size	Typography, spacing scales, global dimensions	Depends on the root font size, not the parent

A useful mental model is:

• px: keep this dimension precise;
• em: scale this with the component;
• rem: scale this with the document’s base typography.

That is more useful than memorizing conversion tables.

When applying the same reasoning to WordPress, remember that frontend themes, the Block Editor and wp-admin are separate styling contexts. A unit strategy that works well in a theme should still be tested independently inside the editor and administration interface.

Related guides

• WordPress Block Editor CSS, Explained
• Making the WordPress Admin More Readable
• Self-Hosted Fonts vs. Google Fonts in WordPress
• WordPress Admin Menu Responsive Breakpoints, Explained
• wp_enqueue_scripts Explained

Final recommendation

Do not choose between px, em and rem as if one unit has to win.

They describe different relationships.

Use rem when a value should remain connected to the document’s root typography. This makes it particularly useful for font sizes, spacing systems and design tokens that need consistent scaling across the site.

Use em when a value should follow the typography of the component itself. Buttons, badges, icons and other self-contained interface elements often benefit from this behavior because their internal dimensions can scale automatically when their local font size changes.

Use px when a stable CSS-pixel dimension is genuinely the clearest expression of the design requirement. A one-pixel border does not become inherently better because it has been converted into a complicated fractional rem value.

Most importantly, stop treating unit selection as a conversion exercise.

Instead of asking how many rem equal a particular number of pixels, ask what the dimension should respond to.

If it should follow the root typography, use a root-relative unit. If it should follow the component, use a local font-relative unit. If it should remain a precise CSS length, pixels may be appropriate. If it should follow the viewport, container or layout grid, use a unit designed for that relationship.

Once CSS units are understood this way, px, em and rem stop being competing alternatives and become different tools for expressing how an interface should scale.