CSS Units Explained: px, rem, em, and Viewport Units

CSS units are one of those fundamentals that many developers learn just enough of to get by, without ever developing a deep understanding of how each unit behaves and when to use it. The result is stylesheets that mix units inconsistently, layouts that break on different screen sizes, and accessibility failures that could have been avoided with better unit choices. Taking the time to understand CSS units properly pays dividends across every project you build.

At a high level, CSS units fall into two categories: absolute units and relative units. Absolute units — primarily pixels (px) — have a fixed size regardless of context. Relative units — including em, rem, percentages, and viewport units — derive their computed size from some other value, such as the parent element's font size, the root font size, or the browser viewport dimensions. This distinction is fundamental because it determines whether your layout will adapt to different contexts or remain rigidly fixed.

The choice of unit has direct implications for three critical aspects of web development. Accessibility: relative units scale when users change their browser's default font size, which is essential for users with visual impairments who increase the base size for readability. Absolute units do not scale, potentially making your text too small for these users. Responsive design: relative units allow components to adapt to different viewport sizes without explicit media queries for every breakpoint. Maintainability: using relative units consistently means that changing a single root value can cascade adjustments throughout your entire stylesheet, rather than requiring you to update dozens of hardcoded pixel values.

Modern CSS includes more than a dozen unit types, but in practice, web designers work with a core set of about six: px, em, rem, %, vw, and vh. This guide covers each in detail, explains how they compute to final pixel values, and provides clear rules for when to use each one.

The pixel is the most familiar CSS unit and the one most developers reach for first. One CSS pixel does not necessarily equal one physical pixel on the screen — on high-DPI (Retina) displays, one CSS pixel maps to two or more physical pixels. However, the CSS pixel is always the reference point that other units are converted to during layout computation. Understanding this is important because it means px values are not affected by the root font size or any inherited sizing context. A declaration of font-size: 16px always computes to 16 CSS pixels, period.

The predictability of px is both its strength and its weakness. It is easy to reason about — you know exactly what size you are getting. This makes px the right choice for elements that should maintain a consistent physical size regardless of context: borders (a 1px border should always be exactly one pixel), box shadows (shadow offsets and blur radii are best specified in pixels for precise control), small decorative elements (icons, dividers, spacers under 4px), and fixed-position UI chrome (toolbar heights, status bars).

The problem with pixels arises when they are used for font sizes and spacing that should scale with user preferences. If you set body text to font-size: 16px, that text will be 16px regardless of whether the user has set their browser default to 20px for accessibility reasons. The text will be too small for that user, and there is nothing they can do about it short of using browser zoom (which scales the entire page, including images and layout, often breaking the design). This is why accessibility guidelines strongly recommend using relative units for text and spacing.

Another common mistake is using px for media query breakpoints. While px breakpoints work, they do not account for the root font size, which means they do not scale proportionally if the base font size changes. Using em-based breakpoints creates a more proportional responsive system where the layout adapts in concert with the typographic scale.

In modern CSS, the best practice is to use px only where an absolute, context-independent size is genuinely needed — borders, shadows, and tiny decorative elements. For everything else, reach for relative units.

The rem (root em) is arguably the most important unit in modern CSS. One rem equals the computed font size of the root element — the <html> element — which browsers set to 16px by default. This means that 1rem = 16px in most browsers unless the user or developer has changed the root font size. If you set html { font-size: 100%; } in your stylesheet, the root size remains the user's browser default, preserving accessibility.

The power of rem lies in its relationship to a single reference point. Because all rem values derive from the root font size, changing the root size proportionally scales every rem-based measurement in your entire stylesheet. If a user sets their browser default to 20px, every rem value automatically adjusts: 1rem becomes 20px, 1.5rem becomes 30px, and 2rem becomes 40px. Your entire typographic scale, your spacing system, and your component sizes all scale proportionally without any additional code. This is the key to building interfaces that respect user preferences.

Using rem for font sizes is the most common and recommended application. A typographic scale based on rem might look like: body text at 1rem, small text at 0.875rem, large headings at 2rem, and display text at 3rem. Because these values are all relative to the root, adjusting the root size (or having the user adjust it) scales the entire typographic hierarchy proportionally, preserving the visual relationships between text sizes.

Using rem for spacing creates a spacing system that scales with the typography. Define your spacing scale in rem: 0.25rem for tight spacing, 0.5rem for small gaps, 1rem for standard padding, 1.5rem for section spacing, and 2rem for large gaps. When the root font size increases, your spacing increases proportionally, maintaining the visual rhythm of the layout. This creates a cohesive relationship between text size and whitespace that feels natural and professional.

A common pattern is to set the root font size to a percentage that maps to a convenient base value: html { font-size: 62.5%; } sets 1rem to 10px (since 62.5% of 16px = 10px). This makes mental arithmetic trivial — 1.4rem = 14px, 2rem = 20px, 3.2rem = 32px. However, this approach has accessibility implications: if a user has set their browser default to 20px for readability, your 62.5% root brings it down to 12.5px, which is smaller than their preference. A safer approach is to keep the root at 100% and work with the 16px base, or use the 62.5% trick only if you have no accessibility requirements.

The em unit is similar to rem but with a crucial difference: it is relative to the computed font size of the current element rather than the root element. This means that em values compound when elements are nested — a behavior that can be either powerful or confusing depending on how well you understand it.

In a simple case, if an element has font-size: 16px, then 1em = 16px within that element. Setting padding: 1em on that element gives 16px of padding. If you change the font size to 20px, the padding automatically becomes 20px. This proportionality between text size and spacing is what makes em useful for component-level design — the spacing within a component scales automatically when the component's text size changes.

The compounding behavior becomes apparent with nested elements. Consider a list where each level has font-size: 0.9em. At the root level (16px), the first nested level computes to 14.4px. The second nested level computes to 12.96px (0.9 × 14.4px). The third level drops to 11.66px. By the fourth level, the text is nearly unreadable. This compounding is the reason many developers avoid em — it can lead to unexpected sizing if you are not tracking the inheritance chain carefully.

The ideal use case for em is within self-contained components where you want internal spacing to scale with the component's font size. Buttons are a perfect example: a button with padding: 0.5em 1em will have proportionally larger padding when the button text is large and proportionally smaller padding when the text is small. This maintains the visual balance of the button regardless of its text size. Media queries also benefit from em — using em-based breakpoints (such as @media (min-width: 48em)) ensures that the layout responds proportionally to the typographic scale rather than to an absolute pixel width.

em vs rem decision guide: Use rem for any value that should scale with the global root size — page-level font sizes, margins between components, grid columns, and layout-level spacing. Use em for values that should scale with the local component's text size — button padding, inline icon sizes, component-level margins, and media query breakpoints. If you are unsure, default to rem — it is more predictable and avoids the compounding problem entirely.

Viewport units are relative to the browser viewport — the visible area of the web page. 1vw equals 1% of the viewport width, and 1vh equals 1% of the viewport height. On a screen that is 1440px wide, 1vw = 14.4px. On a screen that is 900px wide, 1vw = 9px. These units enable fluid sizing that responds directly to the viewport dimensions without media queries.

Using vw for fluid typography is one of the most powerful applications of viewport units. A heading sized with font-size: 5vw will be 72px on a 1440px screen and 36px on a 720px screen. Combined with the CSS clamp() function, you can set minimum and maximum bounds: font-size: clamp(1.5rem, 5vw, 3rem) ensures the heading is never smaller than 1.5rem or larger than 3rem, while scaling fluidly between those bounds based on the viewport width. This eliminates the need for multiple font-size declarations across breakpoints.

Using vh for full-height sections creates hero sections, landing pages, and full-screen overlays that always fill the viewport. Setting height: 100vh on a section makes it exactly the height of the viewport. However, there is a well-known issue on mobile browsers: the address bar and toolbar affect the measured viewport height, causing 100vh to extend beyond the visible area. Modern CSS provides the dvh (dynamic viewport height) unit to address this — 100dvh always equals the current visible area, accounting for browser chrome. The svh (small viewport height) and lvh (large viewport height) units give you the minimum and maximum possible viewport heights respectively.

vmin and vmax reference the smaller and larger of the two viewport dimensions. On a landscape-oriented screen (wider than tall), 1vmin equals 1vh and 1vmax equals 1vw. On a portrait screen, the relationship flips. These units are useful for elements that should maintain a consistent size relative to the available space regardless of orientation — a square element sized at 50vmin will always take up half of the smaller viewport dimension, fitting comfortably in both landscape and portrait orientations.

Viewport units are best used for page-level layout elements — hero sections, full-width banners, fluid typography, and responsive spacing that should adapt to the viewport without explicit breakpoints. Avoid using viewport units for component-level sizing, where rem and em provide better predictability and accessibility. A card component sized with vw will be unusably small on mobile and comically large on ultra-wide monitors — rem-based sizing with a max-width constraint handles this scenario much better.

Beyond the core units of px, rem, em, and viewport units, CSS provides several specialized units that are valuable in specific contexts. Understanding these units expands your toolkit and helps you choose the most appropriate unit for every situation.

Percentages (%) are relative to the parent element's corresponding dimension. A width: 50% on a child element makes it half the width of its parent. A padding-top: 50% is calculated relative to the parent's width (not height), which is a useful quirk for creating aspect ratio boxes. Percentages are the go-to unit for grid and flexbox layouts where children should fill a proportion of their parent. However, vertical percentages (height, margin-top, padding-top) can behave unexpectedly because they reference the parent's width, not height, unless the parent has an explicit height set.

ch (character unit) equals the width of the "0" character in the current font. This unit is particularly useful for sizing text containers to a readable line length. Research consistently shows that 50-75 characters per line is the optimal range for readability — setting max-width: 65ch on a content container ensures the text width stays in this sweet spot regardless of the font size or viewport width. The ch unit adapts to the actual font being used, so it automatically adjusts if the font changes.

ex is similar to ch but based on the height of the lowercase "x" character. It is less commonly used but can be helpful for vertical alignment and spacing that should relate to the font's x-height rather than its overall size.

fr (fraction) is used exclusively in CSS Grid to distribute available space. Setting grid-template-columns: 1fr 2fr 1fr creates three columns where the middle one is twice as wide as the others. The fr unit distributes space after fixed-size tracks and gaps are accounted for, making it more intuitive than percentages for grid layouts because it avoids the need to subtract gap sizes manually.

lh (line height) is a newer unit equal to the computed line-height of the current element. It is useful for vertical spacing that should relate to the text leading — setting margin-bottom: 1lh ensures spacing between paragraphs matches the line height, creating a consistent vertical rhythm.

Practical unit selection guide: Use px for borders, shadows, and tiny decorative sizes. Use rem for font sizes, spacing scales, and any value that should scale globally. Use em for component-internal spacing and media query breakpoints. Use % for parent-relative sizing in grid and flex layouts. Use vw/vh for full-viewport sections and fluid typography. Use ch for readable line lengths. Use fr for grid column and row sizing. Consistency in unit choice across your stylesheet is as important as choosing the right unit for each individual property.

Converting between CSS units is a routine task that becomes error-prone when you do not understand the underlying reference points. Each unit converts to pixels differently, and getting the conversion wrong can break your layout or accessibility.

rem to px conversion: Multiply the rem value by the root font size. At the default 16px root, 2rem = 32px, 0.75rem = 12px, and 1.5rem = 24px. The inverse — px to rem — is division: 24px ÷ 16 = 1.5rem. This is straightforward when the root is 16px, but many projects use the 62.5% trick (10px base), which changes the arithmetic: at a 10px base, 1.5rem = 15px, not 24px. Always confirm the root font size before converting.

em to px conversion: This requires knowing the current element's computed font size. If an element has font-size: 20px, then 2em of padding = 40px. But if the element's font size is set in em (font-size: 1.25em) and its parent has font-size: 16px, the element's computed font size is 20px, and 2em = 40px. The chain of inheritance must be traced to get an accurate conversion. This complexity is why em-to-px conversions are best done with browser DevTools, which show computed values directly.

vw to px conversion: Multiply the vw value by the viewport width and divide by 100. At a 1440px viewport, 5vw = 72px. At 768px, 5vw = 38.4px. Because the viewport width changes with resizing, vw-based values are inherently fluid. To convert a desired pixel value to vw: (target_px ÷ viewport_width) × 100 = vw value. For example, to get 48px at a 1440px viewport: (48 ÷ 1440) × 100 = 3.33vw.

Common conversion pitfalls: Mixing units within a single property can produce unexpected results. Setting padding: 1rem 16px mixes relative and absolute units, defeating the purpose of using rem in the first place. Be consistent within each declaration. Another pitfall is forgetting that line-height specified without a unit (such as line-height: 1.5) behaves differently from line-height: 1.5em — the unitless value is inherited as a multiplier and recomputed for each child element, while the em value is computed once and the fixed result is inherited. Always use unitless values for line-height to preserve the proportional scaling behavior.

When building design systems, document your unit choices as part of the system's foundation. Specify which unit to use for each category of property: rem for font sizes and spacing, px for borders and shadows, em for component-internal measurements, and % for layout proportions. This documentation ensures consistency across a team and prevents the gradual drift toward px that occurs when developers default to what feels familiar.