Converters

PX to REM in CSS: Complete Guide to Responsive Font Sizing & Unit Conversion

Learn when and how to use REM instead of PX in CSS. Covers the px-to-rem conversion formula, browser default font sizes, the 62.5% technique, EM vs REM differences, accessibility benefits, and Tailwind CSS integration.

Published March 19, 2026
11 minute read
Cryptography Guide

PX to REM in CSS: Complete Guide to Responsive Font Sizing & Unit Conversion

Choosing the right CSS unit is one of those decisions that seems trivial at first and becomes critical at scale. A page built entirely in pixels looks fine on the developer's monitor, but it can break for users who rely on browser font-size settings, zoom controls, or assistive technology. A page built with REM units, by contrast, scales gracefully across every device and every user preference.

This guide walks through everything you need to know about the PX-to-REM relationship: the conversion formula, why REM exists, when each unit is the right choice, and how modern frameworks like Tailwind CSS and Bootstrap handle the conversion for you. Use our free PX to REM converter to follow along with any example below.


What Are PX, REM, and EM Units?

CSS offers more than a dozen length units, but three dominate front-end development: PX, REM, and EM. Understanding what each one measures is the foundation for every conversion decision.

PX (Pixels)

A CSS pixel is an absolute length unit. On a standard-density screen, 1px corresponds to one physical device pixel. On high-DPI (Retina) screens, the browser maps CSS pixels to device pixels using the device pixel ratio, but from the CSS perspective 1px always means the same fixed size.

Pixels are predictable. A border: 1px solid black always renders as a one-pixel line regardless of font size, parent element, or user preferences. That predictability is both the strength and the limitation of the unit.

REM (Root EM)

REM stands for Root EM. It is a relative unit that always refers to the font size of the root <html> element. If the root font size is 16px (the browser default), then 1rem = 16px, 1.5rem = 24px, and 0.75rem = 12px.

The key property of REM is that it has exactly one reference point: the root element. No matter how deeply nested a component is, 1rem always resolves to the same computed size. This makes REM predictable and scalable at the same time.

EM (Relative to Parent)

EM is also a relative unit, but it refers to the computed font size of the element itself (or, for properties other than font-size, the font size of the parent element). If a parent element has font-size: 20px, then 1em inside that parent equals 20px. If a child inside that parent also sets font-size: 1.2em, its computed size becomes 24px, and any em values inside the child now reference 24px.

This compounding behavior makes EM powerful for component-scoped scaling but dangerous in deeply nested structures.


The Conversion Formula

The PX-to-REM formula is a single division:

REM = PX / Root Font Size

And the reverse:

PX = REM x Root Font Size

With the browser default root font size of 16px:

  • 16px / 16 = 1rem
  • 24px / 16 = 1.5rem
  • 14px / 16 = 0.875rem
  • 10px / 16 = 0.625rem

The formula never changes. Only the denominator changes if you override the root font size in your CSS.


Browser Default: The 16px Base

Every major browser -- Chrome, Firefox, Safari, Edge -- ships with a default root font size of 16px. This means that unless your stylesheet explicitly changes it, 1rem = 16px everywhere.

This 16px default is not arbitrary. It was chosen decades ago as a comfortable reading size for body text on desktop monitors, and it has remained the standard ever since. Users can change this default in their browser settings (typically under Settings > Appearance > Font Size), which is a critical accessibility feature.

How to Change the Base Font Size

You can override the root font size in your CSS:

CSS4 lines
Highlighting code...

After this declaration, all REM values across your entire site recalculate relative to 18px. A heading set to 2rem becomes 36px instead of 32px. This is the power of REM: one change at the root cascades everywhere.

However, setting the root font size in pixels has a significant accessibility drawback. It overrides the user's browser font-size preference. A user who set their browser to "Large" (typically 20px) will not see that preference reflected if your stylesheet hardcodes html { font-size: 18px; }.

The better approach is to use a percentage:

CSS4 lines
Highlighting code...

Percentage-based root font sizes are relative to the browser's default, so a user with a 20px preference gets 20 × 1.125 = 22.5px -- their preference is respected and proportionally applied.


The 62.5% Technique

One of the most popular tricks in CSS development is the 62.5% technique. It simplifies mental arithmetic by making 1rem = 10px:

CSS8 lines
Highlighting code...

With this setup, conversions become trivial:

Desired SizeREM Value
10px1rem
12px1.2rem
14px1.4rem
16px1.6rem
18px1.8rem
20px2rem
24px2.4rem
32px3.2rem

Pros

  • Mental math is instant: just move the decimal point.
  • All the accessibility benefits of percentage-based root sizing are preserved. A user with a 20px browser default gets 20 × 0.625 = 12.5px as their effective base, and all REM values scale proportionally.

Cons

  • Every component must use REM. If you forget and use a bare font-size value, text renders at the 10px base, which is unreadable.
  • Third-party components and libraries may not expect a 10px root and can render too small.
  • The body reset to 1.6rem is easy to forget, and forgetting it causes all default text to shrink.

Despite the trade-offs, many teams adopt the 62.5% technique because the mental-math benefit outweighs the setup cost, especially on greenfield projects where the team controls every component.


EM vs REM: When to Use Each

Both EM and REM are relative units, but they serve different design goals.

The Nesting Problem with EM

Consider this HTML structure:

HTML10 lines
Highlighting code...

With this CSS:

CSS4 lines
Highlighting code...

Each level compounds. The grandchild text is 73% larger than the page's base size, even though every element only asked for "1.2em." This compounding makes EM unpredictable in deeply nested layouts.

The Same Example with REM

CSS4 lines
Highlighting code...

Every element resolves to the same 19.2px because REM always references the root, not the parent. No compounding, no surprises.

When EM Is the Better Choice

EM is ideal when you want a property to scale with the element's own font size. Classic examples:

  • Padding and margin on buttons: padding: 0.5em 1em makes a button's internal spacing proportional to its text size. If you later increase the button's font size, the padding scales automatically.
  • Icon sizing alongside text: width: 1em; height: 1em keeps an inline icon the same size as surrounding text.
  • Line-height: line-height: 1.5em (or the unitless 1.5) ensures leading scales with font size.

Rule of Thumb

Use REM for global sizing: font sizes, layout widths, spacing systems, and media queries. Use EM for component-internal scaling where you want proportional behavior tied to the component's own text size.


Accessibility: Why REM Respects User Preferences

Accessibility is the strongest argument for using REM over PX for font sizes. Here is why.

Browser settings include a font-size preference, typically adjustable from "Very Small" (about 9px) to "Very Large" (about 24px). Many users with low vision increase this setting to make all web text larger. The Web Content Accessibility Guidelines (WCAG) 1.4.4 requires that text can be resized up to 200% without loss of content or functionality.

When you set font sizes in pixels, the browser's font-size preference is ignored. A p { font-size: 16px; } renders at 16px whether the user's preference is 12px, 16px, or 24px. The user's only recourse is to use browser zoom (Ctrl/Cmd +), which scales the entire viewport, not just text.

When you set font sizes in REM, the browser's preference becomes the root from which everything else is calculated. A user who sets their preference to 24px gets 1rem = 24px, and your p { font-size: 1rem; } automatically renders at 24px. Headings set to 2rem render at 48px. The entire typographic hierarchy scales proportionally.

This is not a niche concern. Studies estimate that 20-30% of web users adjust their default font size. Supporting their preferences is a matter of both usability and legal compliance in many jurisdictions.


When to Keep Using PX

REM is not the right unit for everything. Several CSS properties work better with fixed pixel values:

Borders

A 1px border should stay 1px regardless of font size. A 0.0625rem border (1/16th of a rem) would round inconsistently across browsers and zoom levels. Use pixels for borders.

CSS5 lines
Highlighting code...

Box Shadows

Shadow offsets and blur radii are visual effects that do not need to scale with text size. Pixels keep shadows consistent:

CSS4 lines
Highlighting code...

Media Queries

Media queries define viewport breakpoints. While you can use REM in media queries (@media (min-width: 48rem)), the behavior is based on the browser's default font size, not your stylesheet's root font size. Using pixels makes breakpoints more predictable and easier to reason about:

CSS2 lines
Highlighting code...

That said, using REM in media queries has an accessibility advantage: if a user increases their browser's default font size, REM-based breakpoints trigger earlier, giving them a layout designed for the effective space available. Some teams consider this a best practice.

Outline and Fine Detail

Outlines, thin decorative lines, and other sub-pixel details that should not scale belong in pixels.

Summary Table

PropertyRecommended UnitReason
Font sizeremRespects user preferences
Padding / marginrem or emScales with layout or component
Width / max-widthrem or %Responsive layouts
Border widthpxConsistent thin lines
Box shadowpxVisual effect, not content
Border radiusrem or pxEither works; rem for consistency
Media queriespx or remPX for simplicity, REM for a11y
Line heightunitlessProportional to font size

PX to REM in Tailwind CSS and Bootstrap

Tailwind CSS

Tailwind CSS uses REM under the hood for nearly all of its spacing and typography utilities. When you write text-base, Tailwind applies font-size: 1rem; line-height: 1.5rem; -- equivalent to 16px/24px at the default root.

Here is how Tailwind's font-size utilities map to PX values (at the 16px default):

Tailwind ClassCSS OutputPX Equivalent
text-xsfont-size: 0.75rem12px
text-smfont-size: 0.875rem14px
text-basefont-size: 1rem16px
text-lgfont-size: 1.125rem18px
text-xlfont-size: 1.25rem20px
text-2xlfont-size: 1.5rem24px
text-3xlfont-size: 1.875rem30px
text-4xlfont-size: 2.25rem36px

Tailwind's spacing scale (p-4, m-8, etc.) is also REM-based: p-4 applies padding: 1rem (16px). This means Tailwind projects inherently respect the user's root font-size preference.

If you need a specific pixel value in Tailwind, use the bracket syntax: text-[18px] or p-[10px]. But prefer the REM-based scale whenever possible.

Bootstrap

Bootstrap 5 also uses REM as its primary unit. The base font size is set on the <html> element (defaulting to the browser's 16px), and all typographic and spacing values are expressed in REM:

  • $font-size-base: 1rem (16px)
  • $h1-font-size: $font-size-base * 2.5 (2.5rem = 40px)
  • $spacer: 1rem (16px), with the spacing scale built as multiples

Bootstrap's $enable-smooth-scroll and $font-size-root Sass variables allow you to customize the base, but the default behavior is fully REM-based.


Complete PX to REM Conversion Reference Table

This table uses the standard 16px root font size. Divide any PX value by 16 to get the REM equivalent.

PXREMPXREMPXREM
10.0625332.0625654.0625
20.125342.125664.125
30.1875352.1875674.1875
40.25362.25684.25
50.3125372.3125694.3125
60.375382.375704.375
70.4375392.4375714.4375
80.5402.5724.5
90.5625412.5625734.5625
100.625422.625744.625
110.6875432.6875754.6875
120.75442.75764.75
130.8125452.8125774.8125
140.875462.875784.875
150.9375472.9375794.9375
161483805
171.0625493.0625815.0625
181.125503.125825.125
191.1875513.1875835.1875
201.25523.25845.25
211.3125533.3125855.3125
221.375543.375865.375
231.4375553.4375875.4375
241.5563.5885.5
251.5625573.5625895.5625
261.625583.625905.625
271.6875593.6875915.6875
281.75603.75925.75
291.8125613.8125935.8125
301.875623.875945.875
311.9375633.9375955.9375
322644966

For quick conversions at any base font size, use our PX to REM converter.


PostCSS and VS Code Tools for Automated Conversion

Manually converting every pixel value to REM is tedious and error-prone. Fortunately, several tools automate the process.

PostCSS Plugin: postcss-pxtorem

The most popular automated solution is postcss-pxtorem. It transforms PX values in your compiled CSS to REM automatically:

Bash2 lines
Highlighting code...

Configuration in postcss.config.js:

JavaScript12 lines
Highlighting code...

With this setup, you write CSS in pixels and the build output uses REM:

CSS6 lines
Highlighting code...

You can exclude specific properties or selectors from conversion. Many teams exclude border and box-shadow properties by customizing the propList or adding /* px-to-rem-disable-next-line */ comments.

VS Code Extensions

Several VS Code extensions provide real-time conversion:

  • px to rem & rem to px (by cipchk): Highlights PX values and shows the REM equivalent on hover. Supports batch conversion of selected text with a keyboard shortcut.
  • CSS REM Converter: Converts inline as you type. Configure the base font size in extension settings.
  • PX to REM: Minimal extension focused on quick conversion via the command palette.

These extensions let you see the REM equivalent without leaving your editor, making the conversion process seamless during development.

Sass/SCSS Function

If you use Sass, a custom function provides compile-time conversion:

Scss11 lines
Highlighting code...

This approach keeps your source code readable in pixel-like values while outputting REM in the compiled CSS.


Frequently Asked Questions

What is the difference between PX and REM in CSS?

PX is an absolute unit that always renders at the same fixed size regardless of user settings. REM is a relative unit that scales based on the root <html> element's font size. If a user increases their browser's default font size, REM values grow proportionally while PX values stay the same. For font sizes and spacing, REM is preferred because it respects accessibility preferences.

How do I convert PX to REM?

Divide the pixel value by the root font size. With the default 16px root: REM = PX / 16. For example, 24px becomes 24 / 16 = 1.5rem, and 14px becomes 14 / 16 = 0.875rem. If you have changed your root font size (e.g., using the 62.5% technique for a 10px base), divide by that base instead: 24 / 10 = 2.4rem.

Why is 1rem equal to 16px?

Because 16px is the default font size that all major browsers apply to the <html> element. Since REM is defined as "relative to the root element's font size," and the root defaults to 16px, 1rem = 16px. You can change this default by setting a different font-size on the html element in your CSS.

Should I use EM or REM for font sizes?

Use REM for font sizes in almost all cases. REM provides consistent, predictable sizing because it always references the root, not the parent element. EM values compound in nested elements, which can cause unexpected size inflation. Reserve EM for component-internal properties like padding and margins where you want spacing to scale with the component's own text size.

Does using REM affect performance?

No. REM values are resolved once during the CSS cascade, just like PX values. There is no runtime performance difference between PX and REM. The browser computes the final pixel value during layout and renders it identically. The only "cost" is developer time during conversion, which tools like PostCSS and VS Code extensions eliminate.

What is the 62.5% font-size technique?

Setting html { font-size: 62.5%; } changes the root font size from 16px to 10px (16 x 0.625 = 10). This makes PX-to-REM math trivial: 14px = 1.4rem, 20px = 2rem, etc. You must add body { font-size: 1.6rem; } to restore readable body text. The technique preserves accessibility because percentages are relative to the user's browser default.

Can I mix PX and REM in the same project?

Yes, and most projects do. The common approach is to use REM for font sizes, padding, margins, and layout widths (anything that should scale with user preferences), while using PX for borders, box shadows, outlines, and other fine visual details that should remain constant. This hybrid approach gives you both accessibility and visual precision.

How does browser zoom interact with REM?

Browser zoom (Ctrl/Cmd +/-) scales the entire viewport proportionally, affecting both PX and REM values equally. It is a separate mechanism from the browser's font-size preference. When a user zooms to 150%, a 1rem element and a 16px element both render 50% larger. The accessibility advantage of REM is specifically about respecting the font-size preference, not about zoom behavior.


Summary

The PX-to-REM conversion is a simple formula with profound implications for web accessibility and responsive design. By expressing sizes in REM, you let every user -- regardless of their vision, device, or preferences -- experience your site at the scale that works for them.

Key takeaways:

  • REM = PX / root font size (default root is 16px)
  • REM respects user preferences; PX does not
  • The 62.5% technique makes mental math easier (1rem = 10px) while preserving accessibility
  • EM compounds in nested elements; REM does not -- prefer REM for most sizing
  • Keep PX for borders, shadows, and fine visual details that should not scale
  • Tailwind CSS and Bootstrap already use REM internally, so their utility classes are accessible by default
  • PostCSS and VS Code extensions automate the conversion so you never need to do the math manually

Ready to convert? Use our free PX to REM converter to instantly translate any pixel value to REM at any base font size, with a complete reference table and copy-ready CSS output.

About This Article

This article is part of our comprehensive converters cipher tutorial series. Learn more about classical cryptography and explore our interactive cipher tools.

More Converters Tutorials

Try Converters Cipher Tool

Put your knowledge into practice with our interactive convertersencryption and decryption tool.

Try Converters Tool