EM to REM Converter

Easily convert EM to REM with our online EM to REM converter. Simplify your responsive design workflow and ensure consistent CSS units across your site.

EM to REM Manual Table Conversion

We’re assuming the standard default browser font-size of 16px.

REM to EM

An EM to REM converter is a browser-based CSS tool that recalculates a font-size or spacing value written in em into its rem equivalent.

Front-end developers and design-system teams run it during implementation, turning pixel or em specifications handed off from a mockup into the rem values a production stylesheet expects. The output is measured against the root html element’s font-size rather than any parent in the chain.

WCAG 2.1 Success Criterion 1.4.10 requires that content reflow into a single column at 400% zoom without two-dimensional scrolling, a layout behavior that rem-based sizing supports more reliably than fixed pixel values (W3C, 2018).

What Is an EM to REM Converter?

An EM to REM converter is a browser-based tool that recalculates a length value written in em into its rem equivalent.

It exists because em values inherit from a parent element, while rem values reference only the root of the document.

Most designers hand off spacing and type sizes as pixel measurements in a mockup.

A converter takes that pixel-based starting point, factors in the parent’s computed size, and outputs a clean rem figure ready to paste into a stylesheet.

What the tool actually does:

• Accepts em, px, percentage, or point values as input
• Applies the em-to-rem formula against a stated or default root size
• Rounds the output to a chosen decimal precision
• Flags values already sitting at the root level, where conversion is a 1:1 pass-through

The category is straightforward. It sits inside the toolbox built around css styling rules, alongside pixel and color converters used daily by front-end teams.

Its differentiating function is narrower and more useful. It removes the mental math of tracing font-size inheritance through nested elements, something few developers do correctly by hand.

EM vs REM: What Is the Difference?

Both units belong to the family of relative units in css, which scale against something else rather than holding a fixed pixel value.

The current definition sits in the CSS Values and Units Module Level 4 specification, maintained by the CSS Working Group.

The em vs rem distinction comes down to which font-size each unit measures against.

How EM Is Calculated

An em value is multiplied against the font-size of its parent element, not the root.

Nest three elements with their own font-size declarations, and an em value multiplies at every level it passes through.

• 1.5em inside a 20px parent renders at 30px
• That same 1.5em inside a 16px parent renders at 24px

The result depends entirely on where in the document tree the value sits.

How REM Is Calculated

A rem value ignores every parent in between and multiplies only against the root html element’s font-size.

Change one em value halfway down a page and everything below it can shift.

Change the root font-size instead, and every rem value across the entire site scales in lockstep.

Key difference: em is relative to its neighbors, rem is relative to one fixed anchor point.

How an EM to REM Converter Calculates Values

The conversion formula is fixed: rem = em × parent font-size ÷ root font-size.

Every converter, no matter how it’s styled, runs some version of that same equation.

Worked Conversion Example

Take a 1.5em value sitting inside a parent element with a 20px font-size, on a page with the standard 16px root.

1.5 × 20 ÷ 16 gives 1.875rem.

Rounding matters here. Some tools output 1.875rem exactly, others round to 1.88rem, and some trim to 1.9rem depending on the decimal precision setting.

• 1.875rem: full precision, matches the math exactly
• 1.88rem: rounded to two decimals, close enough for most layouts
• 1.9rem: rounded to one decimal, introduces a small but visible size shift

A converter fed a value with no declared parent context has nothing to multiply against, so it either assumes the browser default or asks the user to supply one.

Font-Size Inheritance and Why EM Values Compound

Font-size inheritance is the mechanism, and compounding is what happens when em rides on top of it.

A sidebar set to 1.2em sits inside the body’s 16px default, rendering at 19.2px.

Each level multiplies against the one directly above it, never against the root.

By the fourth nested level, a single 1.2em rule has grown the text by more than 70%, even though nobody touched a number after the first declaration.

Intended compounding happens when a component is built to scale as one unit, like an icon sized in em against its own button’s font-size.

Accidental compounding happens when a stylesheet mixes em values across unrelated nested components without tracking the chain, and sizes drift in ways nobody planned.

Default Root Font Size and Browser Behavior

Every major browser ships with the same default: a 16px font-size on the root html element.

That default is what 1rem equals unless a stylesheet or a user overrides it.

Key figures:

• 16px, the default root font-size in Chrome, Firefox, and Safari (MDN Web Docs)
• 2018, the year rem’s browser support reached Baseline Widely Available, following initial adoption in Chrome 4 and Firefox 3.6 back in 2010 (web-platform-dx / caniuse)
• 62.5%, a common root override (10px effective) some teams use so rem math lands on round numbers

Some teams pair that 62.5% override with media queries that adjust the root value again at wider breakpoints.

That second adjustment changes every rem value on the page in one move, which is the entire point of anchoring to the root instead of a parent.

Chrome DevTools shows the computed root value directly in the inspector, under the html element’s computed styles panel.

A user’s own browser settings can override all of this.

If someone has bumped their default font size to 20px in their browser preferences, every unmodified rem value on the page grows with it, while px stays frozen.

REM, Browser Zoom, and Accessibility Settings

Rem responds to a setting that px was never built to notice: the user’s own font-size preference.

WCAG 2.1 Success Criterion 1.4.4 requires that text can be resized up to 200% without breaking layout or losing content, a baseline most teams treat as core to web accessibility work (W3C).

When a rem-based layout receives a larger root font-size, whether from browser zoom or an accessibility setting, every rem value scales together.

A px-based layout stays exactly the same size no matter what the user asks for.

What actually changes the root:

• Browser zoom, which scales the whole page including the root font-size
• A default font size setting in browser preferences
• Operating-system-level text scaling, on some mobile browsers

WebAIM’s low vision survey found 44% of respondents rely on browser zoom controls, while only 8% had actually increased their browser’s default text size.

That gap matters. Most of the accessibility load falls on zoom, not on the text-size setting, so a layout that only accounts for one of the two is covering the smaller case.

GOV.UK Frontend, the UK government’s shared design system, builds its entire typography scale in rem so resizing stays consistent across every government service that uses it.

The team has run into the edge case directly. On iOS, some Dynamic Type implementations push the effective root size to 17px instead of 16px, which shifts every rem-based measurement slightly and has to be accounted for rather than assumed away.

Building accessible typography around rem doesn’t remove that kind of edge case. It just centralizes the scaling logic in one place instead of scattering it across dozens of hardcoded pixel values.

When to Use REM Instead of EM

Rem fits global typography and spacing. Em fits local, component-level relationships.

That’s the decision in one line, though the reasoning behind it is worth spelling out.

REM works well for:

• Base font-size and heading scales across an entire site
• Spacing tokens in a design system, margin, padding, and gap values
• Any value that should respond to accessibility settings uniformly

EM works well for:

• An icon that should grow or shrink with its own button’s font-size
• Padding inside a component that should scale with that component’s local text size
• Letter-spacing or line-height tied to a single element’s own type size

The responsive typography patterns used in most modern design systems default to rem for the base scale and reserve em for these narrower, local cases.

The U.S. Web Design System builds its typesetting tokens in rem specifically so font sizes stay in sync with a user’s browser preferences rather than a fixed pixel grid.

Pros of defaulting to rem: predictable scaling, one root value to adjust, consistent behavior under browser zoom.

Trade-off: rem gives up the local, self-contained scaling that em provides naturally inside a single component.

Choosing Between PX, EM, and REM for Responsive Typography

Px ignores everything around it. It stays the same size no matter what the browser, the parent, or the user asks for.

Em and rem both scale, but against different anchors, the same distinction covered earlier in this piece.

Most design systems settle on rem as the default for body text and headings, then reach for px only where a fixed value genuinely makes sense, like a 1px border.

Bootstrap’s own documentation sets its base font-size in rem specifically because the browser’s default root value gives visitors a more accessible type scale than a hardcoded pixel value would.

That single decision, rem for the base scale, shapes how every component built on the framework handles responsive design work down the line.

Rule of thumb: if a value should shrink or grow with user preference, use rem. If it needs to stay fixed regardless of settings, use px.

Is Manual Conversion Accurate Enough, or Do You Need a Tool?

Manual math works fine for a single, shallow em value with one known parent.

Multiply, divide, done. No tool required.

Manual math breaks down when:

• The value sits three or more levels deep in nested elements
• A stylesheet carries dozens of overrides across different breakpoints
• Design files hand off px values in bulk rather than one at a time

A design handoff from a tool like Figma or Adobe XD typically arrives as a spec sheet full of pixel values, not em or rem.

Converting twenty or thirty of those by hand invites the same rounding and tracking errors a formula is supposed to prevent.

Error risk rises with the size of the stylesheet, not with the difficulty of the formula itself.

How to Convert EM to REM Step by Step

The process holds regardless of which converter or method does the math.

1. Confirm the root font-size, checking the browser inspector or the project’s own CSS in case it has been overridden from the 16px default
2. Trace the full parent chain for the em value being converted, noting every font-size declaration between it and the root
3. Multiply the em value by the parent’s font-size to get a pixel figure
4. Divide that pixel figure by the root font-size to get the rem value
5. Round to a consistent decimal precision across the stylesheet
6. Verify the rendered result in the browser before shipping it

Skipping step one is the most common way this process goes wrong. A converter that assumes a 16px root when the project actually overrides it to 10px hands back a value that’s off by 60%.

Automating EM to REM Conversion in Sass, PostCSS, and Tailwind

Manual conversion doesn’t scale across a large codebase. Automation does.

Sass Mixins

Function-based conversion:

• A Sass function takes a pixel value and returns the rem equivalent at build time
• The base font-size becomes a single configurable variable
• Every component references that variable instead of a hardcoded number

IBM’s Carbon Design System ships exactly this pattern through its @carbon/layout package, with a rem() function and a $base-font-size variable teams can override across the whole system.

Changing that one variable, say from 16px to 18px, updates every rem calculation the package generates.

PostCSS Plugins

postcss-pxtorem converts every px value in a stylesheet to rem during the build step, no manual tracing required.

Its default configuration sets the root value at 16 and rounds output to five decimal places of precision, according to the plugin’s own documentation.

Typical setup: point the plugin at font-size, line-height, and letter-spacing properties, leave border widths on the exclusion list, and let the build pipeline handle the rest.

Tailwind Configuration

Tailwind builds its entire spacing and type scale around rem by default.

• One spacing unit equals 0.25rem, or 4px under the default configuration
• The base type scale multiplies outward from that same 0.25rem unit

Overriding the scale means editing the theme’s spacing object once, in rem, rather than touching individual utility classes across a project.

Common Mistakes When Converting EM to REM

Most conversion errors trace back to a handful of repeatable habits.

Zoom-related bugs add another layer. Borders sized in rem have been documented to disappear entirely when a page is zoomed out in Chrome, a quirk noted in the unit’s own browser compatibility data.

The fix isn’t complicated: confirm the root value before converting anything, keep a single decimal precision standard across the project, and leave intentionally compounding em values alone.

When EM to REM Conversion Does Not Apply

Rem is not a universal replacement for em, and treating it as one causes its own problems.

Cases where converting away from em is the wrong move:

• An icon or badge built to scale with its own button’s font-size, where compounding is the intended behavior
• Fixed UI details like a 1px border or a small drop shadow offset, where px is simpler and nothing is gained from a relative unit
• Legacy codebases with years of inconsistent root overrides, where the math no longer holds cleanly across every component

Older browser engines add a harder limit. Documented compatibility data for the rem unit shows Internet Explorer 9, 10, and 11 don’t support rem values inside the line-height property when applied to before and after pseudo-elements.

A conversion that assumes rem behaves identically everywhere fails silently in exactly that scenario.

Email is its own case. Outlook’s desktop rendering engine is built on Word rather than a standard browser engine, and relative CSS units in general receive inconsistent support across email clients.

A converter is the wrong tool for an email template. Fixed px values, tested directly in the target client, remain the more reliable choice there.

FAQ on Em To Rem Converter

What Does “REM” Stand For?

REM stands for root em. The unit takes its value from the font-size of the root html element, not from any parent in the document tree.

This root-only reference is what separates rem from the parent-relative behavior of em.

What Does “EM” Stand For?

Em traces back to typography, where the unit originally measured the width of the letter M in a given typeface.

In CSS, it measures a font-size relative to the parent element, carrying that print-era name into a relative web unit.

Is REM the Same Value as PX?

Not by default, though the two can match. At the standard 16px root font-size, 1rem equals 16px exactly.

Change the root font-size and that equivalence breaks, since rem stays relative while px stays fixed.

Do CSS Frameworks Default to REM or EM?

Most modern frameworks default to rem for the base typography and spacing scale, since it responds to browser accessibility settings.

Individual components, like a badge counter sized against its own label, often still use em locally.

Can You Convert REM Back Into EM?

Yes. Reverse the formula: em equals the rem value multiplied by the root font-size, then divided by the parent element’s font-size.

The math runs in either direction as long as both font-size values are known.

Does Every Browser Support REM Units?

Every actively maintained browser supports rem today.

The only lingering gaps sit in retired engines, like older Internet Explorer’s limited handling of rem inside line-height on pseudo-elements, an edge case unlikely to affect a current production site.

What Should You Check First When an EM to REM Converter Returns an Unexpected Value?

An EM to REM converter returns an unexpected value most often because the root font-size it assumed at calculation time does not match the root font-size the live page actually renders once a stylesheet or a user override changes it.

A 16px root scaled to WCAG 2.1’s 400% reflow threshold reaches 64px, a figure neither the browser default nor the reflow criterion states on its own, and it explains why rem-based layouts clear that requirement without extra rules.

That advantage holds only while nothing downstream resets the root value; a single overriding font-size rule on html or body breaks the calculation for every rem value beneath it.

Teams standardizing a type scale around rem typically move next to css viewport units, the sibling technique for sizing elements against screen width rather than font-size.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web and graphic design, focusing on creating user-friendly websites, innovative UI kits, and unique fonts.

Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What is Backend in Web Development? - September 13, 2026
• What is Frontend Development? - September 11, 2026
• How to Make a Button in Figma: Design Best Practices - September 10, 2026