REM to PX Converter
Instantly convert REM values to pixels based on any root font size.
What Is a REM to PX Converter?
A REM to PX converter translates relative CSS units into exact pixel values, so you always know what your code will render on screen. REM is clean and scalable. But pixels are concrete. Sometimes you need both.
REM vs PX: The Core Difference
PX (pixels) are fixed. One pixel is one pixel, regardless of anything else on the page. REM (root em) is relative to the <html> element's font size. By default, browsers set that to 16px, which means 1rem = 16px. Change the root size and every REM value on the page scales with it. That's the power.
| REM | PX (base 16px) | PX (base 18px) |
|---|---|---|
| 0.5rem | 8px | 9px |
| 1rem | 16px | 18px |
| 1.5rem | 24px | 27px |
| 2rem | 32px | 36px |
When to Use REM
- Typography - Font sizes defined in REM scale gracefully when users change their browser's default font size, which is a core accessibility requirement.
- Spacing and layout - Margins, padding, and gaps in REM stay proportional across breakpoints without manual overrides.
- Component libraries - Design systems built on REM are easier to theme. One variable controls everything.
When PX Still Makes Sense
Not everything should scale. Borders, shadows, and icon strokes often look better as fixed pixel values. A 1px border should stay 1px. Use PX for decorative details and REM for content.
The Formula
The math is simple:
pixels = rem × root font size
So 1.25rem at a 16px base equals 20px. At an 18px base, the same value becomes 22.5px. The base matters. Always check it.
Further Reading
What Is the REM to PX Formula?
The formula is: px = rem × root font size
At the 16px browser default, 1.5rem × 16 = 24px. The inverse is rem = px ÷ root font size, which gives you 24 ÷ 16 = 1.5rem.
The root font size is the only variable that changes the output. Two projects can use identical rem values in their CSS and render completely different pixel sizes if their root font sizes differ. This is why confirming getComputedStyle(document.documentElement).fontSize in DevTools before converting matters - the authored value and the computed value don't always match.
REM to PX Conversion Table (Common Values)
Conversion Table at 16px Root (Default)
|
REM |
PX (16px root) |
Common Use |
|---|---|---|
|
0.25rem |
4px |
Fine borders, thin dividers |
|
0.5rem |
8px |
Small spacing, icon padding |
|
0.875rem |
14px |
Secondary text, captions |
|
1rem |
16px |
Body text baseline |
|
1.125rem |
18px |
Large body, lead paragraphs |
|
1.5rem |
24px |
H3 headings, large labels |
|
2rem |
32px |
H2 headings |
|
3rem |
48px |
H1 display text |
|
4rem |
64px |
Hero headlines |
Tailwind CSS builds its entire default spacing scale on this 16px root. Its text-base class outputs exactly 1rem (16px), text-xl outputs 1.25rem (20px), and text-4xl outputs 2.25rem (36px).
Conversion Table at 14px and 18px Root
|
REM |
PX (14px root) |
PX (18px root) |
|---|---|---|
|
0.875rem |
12.25px |
15.75px |
|
1rem |
14px |
18px |
|
1.25rem |
17.5px |
22.5px |
|
1.5rem |
21px |
27px |
|
2rem |
28px |
36px |
Projects targeting older audiences - where Health Literacy Online recommends a minimum body font of 19px - often set an 18px root. A 1rem body text renders at 18px automatically, with no per-element overrides needed.
What Is REM in CSS?
REM stands for "root em." It is a relative CSS unit calculated against the font-size of the <html> element, not against any parent container.
W3C defines rem in the CSS Values and Units Module Level 3. The spec makes the calculation direct: multiply the rem value by the computed font-size of the root element. There are no nesting side effects.
REM vs. EM - What Changes the Calculated Value
rem resolves against the <html> root. It stays consistent regardless of nesting depth.
em resolves against the nearest parent element with a defined font size. Nest three em-sized containers and the computed value compounds with each level.
CSS-Tricks documents this compounding problem directly: a <p> inside a div inside a section, all using em for font size, can produce unexpectedly large text because each level multiplies the previous one. REM eliminates this by anchoring every calculation to one fixed reference point.
How Browsers Compute REM at Runtime
-
The browser loads the user agent stylesheet (default: 16px root).
-
Author stylesheets apply - if the developer sets
html { font-size: 18px; }, the root becomes 18px. -
User preferences apply last. If the user has set their browser to display fonts at 20px, that overrides the author's root unless the author used a fixed
pxvalue. -
Every rem value on the page resolves using the final computed root.
Setting root font size in px bypasses step 3. Setting it as a % or leaving it unset respects the user's browser preference - a distinction with direct WCAG consequences.
What Is PX in CSS?
PX is a CSS absolute unit. 1px equals 1/96th of an inch in the CSS specification, making it device-independent by definition.
The W3C CSS specification distinguishes between CSS pixels (logical units used in stylesheets) and physical pixels (actual hardware dots on a display). These are not the same.
CSS Pixels vs. Physical Pixels on High-DPI Screens
Device Pixel Ratio (DPR) describes the relationship between CSS pixels and physical pixels.
On a standard display, DPR = 1. One CSS pixel maps to one physical pixel. On a Retina (2x) display, DPR = 2 - one CSS pixel renders across 4 physical pixels, producing sharper output. This is why a 1px CSS border still looks thin and clean on a Retina screen rather than appearing as a blurry two-pixel smear.
|
Display Type |
DPR |
Physical pixels per 1 CSS px |
|---|---|---|
|
Standard monitor |
1x |
1 |
|
Retina / HiDPI |
2x |
4 |
|
High-end mobile |
3x |
9 |
PX is appropriate for: borders, box shadows, fixed-dimension media, and layout breakpoints where exact pixel precision matters.
PX creates problems for: body text and typographic scale, where locking sizes in px overrides user browser font preferences and fails WCAG 2.1 Success Criterion 1.4.4.
Why Developers Convert REM to PX?
Design tools output in pixels. CSS best practice demands rem. The gap between those two realities is exactly why rem to px conversion is a daily workflow step for frontend developers.
Figma's native inspection panel displays all measurements in px. Developers reading a Figma spec must either convert manually, use Figma Dev Mode's built-in rem toggle (introduced in 2023 and calculated at 16px root by default), or rely on plugins like "Px Em" to do the arithmetic inline. Without a conversion tool, a developer working from a Figma file risks transcribing px values directly into CSS - creating layouts that ignore user font preferences.
The 4 most common reasons developers convert:
-
Design handoff friction: Figma, Adobe XD, and Sketch all work natively in px. Every measurement handed to a developer needs translation before it enters a rem-based stylesheet.
-
DevTools inspection: Chrome DevTools and Firefox Developer Edition report computed values in px regardless of the unit used in the source CSS. A developer auditing a live page sees px; the stylesheet uses rem. Converting in both directions is part of debugging.
-
Design system token mapping: Tools like Style Dictionary transform px-based design tokens into rem for CSS output. Verifying that transformation requires knowing exactly what px value each rem token produces.
-
WCAG compliance auditing: WCAG 2.1 SC 1.4.4 requires text to scale to 200% without loss of functionality. Auditors check that font sizes are set in rem or
%, not px. Converting px specs to rem before implementation prevents the failure before it occurs.
According to the WebAIM Million 2024 report, 95.9% of tested home pages had at least one WCAG failure - an environment where unit-level decisions directly contribute to audit failures (WebAIM, 2024).
Tailwind CSS sidesteps part of this problem by compiling rem values into its output stylesheet, even though its configuration file uses px. text-base produces font-size: 1rem in the compiled CSS, not 16px. Developers who understand this translation can trust the framework's output aligns with browser accessibility expectations.
For related CSS unit conversions, the same px-based formula applies whether you're working with EM to PX or calculating values between other absolute and relative units.
How Does Root Font Size Affect All REM Values on a Page?
Every rem value on a page resolves against the same single number: the computed font size of the <html> element. Change that number and everything using rem shifts proportionally, at once, with no per-element overrides required.
That cascade is rem's most powerful characteristic. It's also where the most common miscalculations happen.
The 62.5% Root Font Size Technique - Benefits and Risks
The appeal: Setting html { font-size: 62.5%; } makes 1rem equal 10px, turning rem-to-px arithmetic into simple decimal shifts. 24px becomes 2.4rem. 48px becomes 4.8rem. No division by 16 required.
The actual behavior: The 62.5% value is relative to the browser's default font size. At 16px default, 62.5% resolves to 10px. But if a user has set their browser to 20px, 62.5% of that is 12.5px - and every rem value on the page shifts accordingly.
The real risks:
-
Third-party widgets, embedded forms, and browser extensions inherit the modified root and render smaller than expected
-
Removing the 62.5% root from an established codebase requires recalculating every rem value in the project
-
FED Mentor's analysis shows the technique benefits developers, not users - the only advantage is faster mental math during authoring
The alternative: Use a Sass function - @function rem($size) { @return math.div($size, 16px) * 1rem; } - to handle px-to-rem conversion at compile time, keeping the root at its accessible default.
REM in Responsive Design and Media Queries
REM-based media queries and px-based media queries produce different breakpoint behavior when a user's browser font size is not 16px.
A query written as @media (min-width: 48rem) fires at 768px for a 16px root. For a user who has set their browser to 20px, that same query fires at 960px. The layout shift happens earlier on a wider screen than the developer intended.
Media Queries in REM vs. PX - Behavioral Difference
|
Unit |
Behavior |
Affected by user font preference |
|---|---|---|
|
px breakpoints |
Fire at a fixed CSS pixel width |
No |
|
rem breakpoints |
Fire at root-relative width |
Yes |
|
em breakpoints |
Fire at parent-relative width |
Yes (indirect) |
Tailwind CSS uses rem for its breakpoint values in compiled output. Its md breakpoint is 48rem, lg is 64rem. On a default 16px root these equal 768px and 1024px. On a 20px root they fire at 960px and 1280px. Developers using Tailwind on projects with a modified root need to verify breakpoints reflect the intended layout changes.
CSS clamp() integrates naturally into a rem-based type scale. The function font-size: clamp(1rem, 2.5vw, 1.5rem) sets a fluid size that scales with viewport width but stays bounded between 16px and 24px at the default 16px root. Both the min and max values shift if the root changes. Using a Type Scale Generator helps verify that clamp bounds stay within intended px ranges across different root sizes before committing values to production.
REM, PX, and Accessibility Compliance
Locking body font size in px overrides a user's browser font preference. For users with low vision who rely on that preference, fixed px typography is a functional barrier.
The W3C WAI tutorials state it directly: font size should be defined in relative units such as %, em, or rem. Text set in pixels cannot be resized independently from the rest of the page in some browsers (W3C WAI, 2024).
What the WCAG requires:
-
SC 1.4.4 (Resize Text, Level AA): Text must resize to 200% without loss of content or functionality
-
SC 1.4.12 (Text Spacing, Level AA): Layouts must not break when line height is set to 1.5x font size
-
Absolute units like
pxonfont-sizefail SC 1.4.4 in browsers that do not treat browser zoom as a substitute for font size preference
The WebAIM Million 2025 report found 94.8% of tested home pages had at least one WCAG failure (WebAIM, 2025). Font sizing is a documented contributor, particularly on pages where developers copy px values directly from Figma specs without converting to rem.
Setting body font size as 100% (inheriting the browser default) is the simplest accessible baseline. From that point, all typographic scaling in rem units flows from a root the user controls.
REM to PX in Design Systems and Tokens
Design tokens define the visual values of a system - spacing, type scale, color - as named, reusable constants. Most token pipelines store values in px and output them in rem. The conversion happens in the build step, not by hand.
Style Dictionary, the most widely used token transformation tool, accepts a px-based JSON token file and outputs platform-specific formats. For web targets, it converts 16px → 1rem automatically using a configurable root font size value in the transformer config.
How Style Dictionary Converts PX Tokens to REM
Source token (JSON): "font-size-body": { "value": "16px", "type": "dimension" }
Output CSS variable: --font-size-body: 1rem;
The transformer divides every dimension value by the root font size. Change the root from 16 to 18 in the config and all output rem values recalculate. No token values need editing.
Tailwind CSS 4 extends this model with its @theme block. Design tokens defined in @theme are exposed as CSS custom properties and generate utility classes simultaneously. A single token definition produces both var(--font-size-base) for custom CSS and text-base as a utility class - both resolving to 1rem at the 16px default.
Reading Figma Specs in PX and Applying REM in CSS
Figma's Dev Mode includes a px-to-rem toggle that converts all inspected measurements using a 16px root assumption.
Teams using a non-default root need to disable that toggle and convert manually (or via a Figma plugin). Entering the wrong root into Dev Mode produces accurate-looking but incorrect rem values - a silent error that only surfaces when computed px values are checked in Chrome DevTools.
The workflow that prevents this: confirm getComputedStyle(document.documentElement).fontSize on a live build before converting any Figma spec. One console check eliminates all root-assumption errors before they enter the stylesheet.
For color work alongside unit conversion, tools like the RGB to HEX Converter and HEX to RGB Converter complete the design token translation workflow - handling color format conversions the same way this converter handles unit conversions.
Common REM to PX Conversion Errors and How to Fix Them
Most rem calculation errors share one cause: assuming the root font size without verifying it.
The formula is fixed. The root font size is not.
Error 1: Converting against 16px when the root has been changed
A project using html { font-size: 62.5%; } sets the root to 10px. Entering rem values into a converter set to 16px produces results that are 60% larger than the actual rendered output.
Fix: run getComputedStyle(document.documentElement).fontSize in the browser console before converting. Use the returned value, not a default assumption.
Error 2: Applying the 62.5% technique and breaking third-party components
Embedded widgets, chat tools, and payment forms inherit the modified root. A 1rem label inside a Stripe payment form renders at 10px instead of 16px, creating a legibility failure the developer's own styles cannot fix.
Fix: scope the 62.5% reset to a wrapper class rather than the root element, or use a Sass rem function and keep the root at its accessible default.
Error 3: Mixing px and rem breakpoints in the same stylesheet
Spacing defined in rem and media query breakpoints defined in px do not scale together. At a 20px user root, the rem-based spacing expands while the px breakpoints stay fixed. Layout breaks at widths the developer never tested.
Fix: standardize all breakpoints to rem. Tailwind CSS does this by default in its compiled output.
Error 4: Treating em and rem as interchangeable
Both are relative units. Both depend on font size. But em compounds through the DOM tree while rem does not. Three nested containers using em for padding each multiply the previous level.
Fix: use rem for all values that should stay consistent regardless of nesting. Reserve em for elements where scaling relative to the local font size is intentional - button padding that should grow with button text is the clearest use case.
For unit conversions in the opposite direction, a PX to REM converter applies the same formula in reverse: divide the px value by the root font size. The same root verification step applies before converting either direction.
When working across multiple CSS unit types in one project, having converters for adjacent units reduces cross-unit errors. The REM to EM and EM to REM conversions follow the same root-dependent formula and carry the same root-verification requirement.
FAQ on REM to PX Converter
How do I convert REM to PX?
Multiply the rem value by the root font size. At the browser default of 16px, 1.5rem × 16 = 24px. If your project uses a different root, substitute that value instead of 16.
What is 1rem in pixels?
At the standard browser default, 1rem equals 16px. This only holds when the root font size is 16px. If the <html> element has been set to 62.5% (10px) or any other value, 1rem changes accordingly.
Why does my REM to PX conversion give the wrong result?
The root font size in your project differs from the converter's default. Run getComputedStyle(document.documentElement).fontSize in Chrome DevTools or Firefox Developer Edition, then enter that value into the root font size field before converting.
What is the difference between REM and PX in CSS?
PX is an absolute CSS unit - it stays fixed regardless of user settings. REM is a relative unit tied to the <html> element's font size, so it scales when the user changes their browser's default font preference.
Should I use REM or PX for font sizes?
Use rem for font sizes. It respects user browser preferences and satisfies WCAG 2.1 Success Criterion 1.4.4, which requires text to resize to 200% without loss of functionality. PX overrides those preferences entirely.
What is the 62.5% root font size trick?
Setting html { font-size: 62.5%; } makes 1rem equal 10px, simplifying rem-to-px arithmetic. The tradeoff: third-party components inherit the modified root and can render smaller than expected, creating accessibility and layout issues.
Does Tailwind CSS use REM or PX?
Tailwind CSS outputs rem units in its compiled stylesheet, even though its configuration file uses px values. Its text-base class produces font-size: 1rem, and all spacing utilities are rem-based at the 16px root default.
How do media queries behave differently in REM vs PX?
A rem-based breakpoint like @media (min-width: 48rem) responds to the user's root font size. At 20px root it fires at 960px, not 768px. A px breakpoint fires at a fixed width regardless of any font preference.
Can I use a REM to PX converter for spacing and layout, not just fonts?
Yes. The same formula - px = rem × root font size - applies to padding, margin, width, and any other CSS property using rem. Design token pipelines like Style Dictionary use this conversion for entire spacing scales.
What other CSS unit converters are related to REM to PX?
The most directly connected are PX to EM and PT to PX. For print design handoffs, PX to Inches and PX to MM handle absolute unit translation using the same root-dependent calculation logic.
| REM | Pixels | Common Use |
|---|