- Design Resources
- Inspiration
- Web Design
- Logos
- Graphic Design
- UI Design
- UX
- Advertising
- Motion graphics
- Infographics
- Wallpapers
- Various
- About Us
- Contact
Enter a REM value and the font size context to get the equivalent EM instantly.
When root and parent font sizes are the same (typically 16px each), 1rem and 1em produce the same result. The difference emerges when a parent element overrides its font size.
For example: 1.5rem with a 16px root always computes to 24px. But in EM, if the parent is 20px, you need 1.2em (not 1.5em) to get the same 24px result. This converter handles that math for you.
EM values are relative to the parent element font size. REM values are relative to the root font size. Default root is 16px.
This REM to EM converter instantly calculates the correct EM value based on your root and parent font sizes. No guessing. No mental math.
REM and EM look similar but behave differently. REM is always relative to the root <html> font size. EM is relative to the nearest parent element's font size. When those two sizes match, the values are identical. When they differ, things break in ways that are hard to debug.
Getting this conversion wrong leads to inconsistent spacing, misaligned type scales, and layouts that only look right at one breakpoint.
<html>).If root and parent differ, the tool flags it. That warning exists for a reason: nested font sizes are where EM bugs hide.
| Unit | Relative to | Cascades? | Best used for |
|---|---|---|---|
rem |
Root <html> font size |
No | Global spacing, type scale |
em |
Parent element font size | Yes | Component-scoped sizing |
REM is the safer default for most cases. But EM has a specific superpower: it scales with its parent. That makes it ideal for components that need to adapt when their container's font size changes, such as buttons, badges, or icons that should grow or shrink proportionally alongside their label text.
Further reading: CSS values and units on MDN and the W3C spec on font-relative lengths.
A REM to EM converter is a tool or formula that transforms root-relative CSS length values (REM) into parent-relative CSS length values (EM).
The conversion output changes depending on 3 variables: the REM value itself, the root font size set on the <html> element, and the computed font size of the parent element in context.
Formula: EM = REM × (Root Font Size ÷ Parent Font Size)
When both the root and parent font sizes are equal (typically 16px by default in all major browsers), 1rem equals 1em exactly. The moment those two values diverge, the conversion ratio shifts.
Converters exist in 3 forms: online calculators that accept inputs and return EM output instantly, Sass or LESS preprocessor functions embedded in a build process, and manual calculation using the formula above.
The Internet Archive found that 3.08% of users actively change their browser's default font size (Evan Minto, 2018). That's a bigger share than the combined market share of Internet Explorer, Edge, and Opera Mini at the time. Which is exactly why using relative CSS length units matters.
Both REM and EM are relative CSS units used for font sizing, spacing, and layout scaling. The difference is which element they reference: REM always points to the root, EM always points to the parent.
|
Feature |
REM |
EM |
|---|---|---|
|
Reference element |
|
Direct parent element |
|
Affected by nesting |
No |
Yes, compounds with depth |
|
Predictability |
High |
Context-dependent |
|
Best use case |
Global type scale, layout |
Component-scoped spacing |
REM (Root EM) calculates its value from the computed font size of the <html> element, regardless of where in the DOM the element sits.
By default, every major browser sets the root font size to 16px. So 1rem = 16px, 1.5rem = 24px, 2rem = 32px, every time, everywhere in the document.
If a developer sets html { font-size: 20px; }, then 1rem equals 20px across the entire page. That single change cascades to every rem-based value simultaneously, which is why rem works well for typography scales and global spacing systems.
REM does not compound with nesting. A 1rem value inside a 5-level deep DOM element still resolves to exactly the same pixel value as it would at the top level.
EM calculates from the computed font size of the nearest parent element, not the root. That makes the same EM value produce different pixel results depending on where it lives in the DOM.
A classic nesting example from MDN Web Docs shows the problem directly. Set every level to 1.2em and after 3 levels of nesting, the computed size is 1.2 × 1.2 × 1.2 = 1.728 times the base, which is 27.65px when starting from a 16px root (MDN, 2024).
That compounding behavior is why REM was created. As the MDN font-size documentation states, "rem values were invented in order to sidestep the compounding problem."
EM is still useful when the goal is to scale an element proportionally to its local context. Buttons, badges, and form inputs often benefit from EM-based padding so their internal spacing scales when the component's font size changes.
The REM to EM conversion formula requires 3 inputs: the REM value, the root font size in pixels, and the parent element's font size in pixels.
EM = REM × (Root Font Size ÷ Parent Font Size)
When root font size equals parent font size, the ratio inside the parentheses equals 1. The EM output matches the REM input exactly.
This is the most common scenario: root at 16px, parent also inheriting 16px from body. In this case, 2rem = 2em, 0.75rem = 0.75em, and so on.
The ratio diverges as soon as the parent font size changes from the root. 3 practical examples:
Root 16px, parent 20px: 2rem × (16 ÷ 20) = 2 × 0.8 = 1.6em
Root 16px, parent 12px: 1rem × (16 ÷ 12) = 1 × 1.333 = 1.333em
Root 20px, parent 16px: 1.5rem × (20 ÷ 16) = 1.5 × 1.25 = 1.875em
Chrome DevTools and Firefox DevTools both expose the computed font size of any element.
Open DevTools, select the element, go to the Computed tab, and search for font-size. The value shown is the resolved pixel size the browser is using for that element, which is the number you plug into the formula as "Parent Font Size."
The tables below cover the most frequently used REM values at 3 common root and parent font size combinations. These cover most real-world scenarios.
When root and parent match at the browser default, conversion is direct.
|
REM |
EM |
Computed (px) |
|---|---|---|
|
0.25rem |
0.25em |
4px |
|
0.5rem |
0.5em |
8px |
|
0.75rem |
0.75em |
12px |
|
1rem |
1em |
16px |
|
1.25rem |
1.25em |
20px |
|
1.5rem |
1.5em |
24px |
|
2rem |
2em |
32px |
Ratio: 0.8. This applies when a parent element has been explicitly set to 20px, a common choice for section headers or card components that carry larger base text.
|
REM |
EM |
Computed (px) |
|---|---|---|
|
0.5rem |
0.4em |
8px |
|
1rem |
0.8em |
16px |
|
1.5rem |
1.2em |
24px |
|
2rem |
1.6em |
32px |
|
2.5rem |
2em |
40px |
Ratio: 1.25. This scenario applies when a designer has overridden the root to 20px for a larger base scale, but a specific component resets its font size to 16px.
|
REM |
EM |
Computed (px) |
|---|---|---|
|
0.5rem |
0.625em |
10px |
|
1rem |
1.25em |
20px |
|
1.5rem |
1.875em |
30px |
|
2rem |
2.5em |
40px |
The further the root and parent values drift from each other, the more the EM output deviates from the REM input. Any converter tool requires all 3 inputs to give accurate results.
Nesting affects EM values at every level. REM is immune to nesting entirely.
The compounding effect: Each EM-valued element multiplies the font size of its parent. At 1.2em per level across 3 levels, the third element resolves to 1.2³ = 1.728 times the starting size. At 4 levels, it's 1.2⁴ = 2.0736. The text grows whether you intended it to or not.
SkillForge documented a classic case: a nested list set to 0.8em at each level. Every nested <li> becomes 80% of the previous one. After 3 levels of nesting, the text is at 0.8 × 0.8 × 0.8 = 51.2% of the original size (SkillForge, 2015). Nearly unreadable.
The same issue shows up in:
Navigation dropdowns with sub-menus
Comment threads with nested replies
Accordion content inside modal dialogs
Lists inside card components that already have a local font size
REM eliminates this entirely. A 0.8rem value inside a 3-level deep list is still 0.8rem, resolved straight from the root.
Component-level scaling is where EM earns its place. If a button's font size changes, EM-based padding around the button label scales with it automatically. REM-based padding stays fixed no matter what the button's font size does.
The practical solution most codebases land on: use rem for global spacing and typographic scale, use em for internal component proportions where elements should scale relative to their local context.
Online REM to EM converter tools require 3 inputs to function accurately: the REM value, the root font size in pixels, and the parent element's font size in pixels.
Most tools default the root to 16px (matching the browser default), but leave the parent font size field for the user to fill in. Leaving the parent font size at 16px when the actual parent is different will return a wrong EM value.
A well-built converter returns 2 values:
The EM result based on the formula
The computed pixel value, which confirms whether the output matches the intended visual size
Some tools also show the full formula with the values substituted in, which helps when debugging a specific discrepancy in a live stylesheet.
Browser DevTools is the most reliable source for the parent font size value. In Chrome, right-click the parent element, select Inspect, click the Computed tab in the sidebar, and search font-size. The value shown is the final resolved size the browser uses, after all inheritance and overrides have applied.
This matters because CSS inheritance can make the actual computed parent font size different from what appears in the stylesheet. A value of inherit, initial, or a percentage in the CSS will not directly tell you the pixel value. DevTools does.
Related conversion tools for other unit pairs: PX to EM, EM to REM, REM to PX, and PX to REM.
CSS has no native function that reads the computed parent font size dynamically and converts REM to EM on the fly. But there are 3 workable approaches depending on the build setup.
CSS custom properties can store the root and parent font sizes as known values, then calc() computes the conversion at render time.
:root {
--root-size: 16;
--parent-size: 20;
}
.component {
font-size: calc(1.5 * (var(--root-size) / var(--parent-size)) * 1em);
}
The limitation: var() inside calc() with unitless numbers works in modern browsers, but the parent font size must be a known, hardcoded value. CSS cannot dynamically read the computed font size of the parent at runtime using this approach.
Sass handles the math cleanly at compile time. A reusable function accepts the REM value, parent size, and an optional root size parameter:
@function rem-to-em($rem, $parent-size, $root-size: 16) {
@return ($rem * $root-size / $parent-size) * 1em;
}
.card-label {
font-size: rem-to-em(1.25, 20); // outputs 1em
}
Root size defaults to 16 but can be overridden when the project uses a non-standard root. The function compiles to a static EM value in the output CSS, so there's no runtime cost.
LESS handles the same operation using @ variable syntax:
@root-size: 16;
@parent-size: 20;
.card-label {
font-size: (1.25 * (@root-size / @parent-size)) * 1em;
}
Preprocessor conversion is more reliable than manual calculation for codebases with multiple components at different font size contexts. A Sass function called consistently across a component library catches errors that manual calculation misses.
For design systems that work with web typography across multiple component sizes, a Sass or PostCSS utility function is worth the setup. It keeps the conversion logic in one place and makes root size changes a single-variable update.
REM to EM conversion comes up in 4 real scenarios: component library development, third-party widget integration, HTML email templating, and design token translation.
|
Scenario |
Why Conversion Is Needed |
Unit Direction |
|---|---|---|
|
Component libraries |
Internal spacing must scale with local font size |
REM → EM |
|
Third-party widgets |
Root font size unknown or overridden |
EM → verify in REM |
|
HTML emails |
Outlook ignores REM entirely |
REM → EM fallback |
|
Design token systems |
Tokens defined in REM, components expect EM |
REM → EM |
Button padding is the clearest case. If a button's font size increases from 1rem to 1.25rem, EM-based padding around the label scales with it. REM-based padding stays fixed, creating visual imbalance.
Material Design 3 (Google's design system) uses EM units for component-internal spacing like padding and line height, while using REM for the global type scale. That separation keeps components self-contained.
Embedding a third-party widget into a page where the root font size has been overridden is tricky. The widget's REM values resolve against your root, not the original developer's 16px assumption.
Converting to EM with an explicit parent font size lets you anchor the widget's sizing to a known context, bypassing root inheritance issues.
REM is not supported in Outlook 2007-2019, Gmail App on Android, or older Samsung email clients (Litmus Email Client Market Share, 2023). EM is the safer relative unit for email templates that must render consistently across clients.
Converting existing REM-based font sizes to EM before pasting into email HTML is a practical step that avoids fallback to browser default sizing in non-supporting clients.
EM is harder to debug, harder to predict across component boundaries, and slightly more resource-intensive for browsers to compute than REM.
Refine.dev notes that deeply nested EM structures require the browser to calculate sizes relative to each parent in the chain, which can lead to reflows and repaints in complex layouts (Refine, 2025). REM only references one element, the root, making the rendering path shorter.
Tracing an unexpected EM size requires walking the entire ancestor chain to find where the parent font size changed. REM requires checking exactly one value: the root.
In a project with 4-5 levels of nested components, each potentially setting a different font size, an EM value 3 levels deep can resolve to something unexpected without any obvious CSS rule to blame.
Chrome DevTools computed styles show the final resolved pixel value, but they don't show which ancestor caused the result. That still requires manual tracing.
The same component placed in 2 different contexts produces 2 different visual sizes when it uses EM internally and its parent font sizes differ.
A card component with padding: 1.5em inside a sidebar with font-size: 14px gets 21px of padding. The same card in a main content area with font-size: 18px gets 27px. Same component, same CSS, different output.
REM eliminates this entirely. EM is only predictable when the parent font size is controlled or explicitly set at the component boundary.
3 situations where keeping REM is the better call:
Global typographic scale systems where all sizes should respond to one root change
CSS media query–driven breakpoints (browsers compute media query units from the root, not the parent)
Shared components deployed across multiple sites where parent context is unknown
Browsers resolve both units during the layout phase of the rendering pipeline, after parsing the CSS and building the CSSOM, and before the paint step.
|
Unit |
Reference |
Cascade Depth |
Reflow Risk |
|---|---|---|---|
|
REM |
|
1 level |
Low |
|
EM |
Nearest parent |
Full chain |
Higher in deep nests |
|
PX |
None |
Absolute |
None |
The browser multiplies the REM value by the computed font size of the <html> element. Chrome, Firefox, Safari, and Edge all default this to 16px unless the user or developer has overridden it (W3Tutorials, 2024).
That single reference point is why REM is predictable. Change html { font-size: 20px; } and every REM value across the entire page updates in one cascade.
The browser reads the computed font size of the parent element, then multiplies by the EM value. If the parent font size is also set in EM, the browser walks further up the ancestor chain to resolve it first.
This chain resolution is what creates the compounding effect. As documented by MDN, nested 1.6em values render "outer" text at 25.6px and "inner" text at 40.96px from a 16px root (MDN Web Docs, 2024). Same value, different results based purely on nesting depth.
Some codebases set html { font-size: 62.5%; } to make 1rem = 10px, simplifying mental math. This changes every REM to EM conversion ratio because the root is now 10px, not 16px.
With 62.5% root: EM = REM × (10 ÷ Parent Font Size)
FED Mentor and other accessibility-focused resources point out that this trick breaks inheritance for components that don't explicitly reset font sizes, particularly form inputs (FED Mentor, 2024). Removing it from a large existing codebase requires recalculating every rem value in the project.
If the codebase you're working in uses the 62.5% trick, update the root font size input in any REM to EM converter from 16 to 10 before calculating.
Both REM and EM values scale when a user changes the default font size in their browser. Pixel values do not.
Research from the Internet Archive found that 3.08% of users set a custom browser font size, a higher share than users of Internet Explorer, Edge, or Opera Mini combined at the time (Evan Minto, Internet Archive, 2018).
When a user changes their default font size in Chrome (Settings > Appearance > Font Size) or Firefox (Settings > General > Fonts), the browser's user agent stylesheet adjusts the root font size accordingly.
A user who sets their default to 20px causes 1rem = 20px on any site that hasn't hardcoded the root
EM values cascade through the same change, since the body font size also inherits from the root unless overridden
Hardcoded html { font-size: 16px; } breaks this scaling entirely, ignoring the user's preference
WCAG Success Criterion 1.4.4 (Resize Text) requires that text be resizable up to 200% without loss of content or functionality (W3C WCAG 2.2, 2023).
Using REM and EM satisfies this requirement. Using pixels does not, because pixel-based fonts ignore browser font size settings in most browsers when the user adjusts preferences (as opposed to browser zoom, which scales everything regardless of unit).
WCAG AA compliance requires a minimum of 16px for normal body text as a practical baseline; for users over 85, an estimated 20% have significant visual impairment (JAMA Network Open), making scalable units critical, not optional.
When users override the root to a non-standard value, REM to EM conversions that were calculated at 16px root become incorrect for that user's session.
The converter formula remains valid. The user just needs to substitute their actual root font size into the calculation. Tools that let you manually set the root font size handle this correctly. Tools that hardcode 16px as a non-editable default do not.
For further reading on related unit conversions, the EM to PX converter and PX to EM converter cover the adjacent conversion paths. The Type Scale Generator is also useful for building a full responsive typographic hierarchy that accounts for user font size preferences across breakpoints.
The formula is EM = REM × (Root Font Size ÷ Parent Font Size).
When both values are 16px, the ratio is 1:1. When they differ, the EM output shifts. You need all three inputs to get an accurate result.
REM references the <html> root element. EM references the direct parent element.
REM stays consistent regardless of nesting depth. EM compounds with each level, producing different pixel values depending on where the element sits in the DOM.
EM values multiply at each nesting level. A parent set to 1.2em and a child also at 1.2em produces 1.2 × 1.2 = 1.44 times the base size.
REM ignores the parent chain entirely, so nesting has no effect on the computed pixel value.
Most browsers default to 16px for the root element. Chrome, Firefox, Safari, and Edge all ship with this value unless a developer or user overrides it.
Converter tools use 16px as the default input, but this should be updated if your project sets a different root size.
Convert when building component-scoped spacing that needs to scale with a local font size, like button padding or card internal spacing.
Also useful when integrating third-party widgets where the root context is unpredictable, or when writing HTML emails where REM support is inconsistent.
Not directly. Both units scale with user browser font size preferences, unlike pixels.
The key is avoiding hardcoded root overrides like html { font-size: 16px; }, which break user preference scaling and can violate WCAG 1.4.4 (Resize Text) requirements.
Open browser DevTools, select the parent element, and check the Computed tab.
Search for font-size. The value shown is the resolved pixel size after all inheritance and overrides, which is the number the conversion formula needs.
Both units scale proportionally. A user setting their default to 20px causes 1rem to equal 20px site-wide.
Pixel-based font sizes ignore this preference entirely. Using relative CSS units like REM and EM is the practical way to support user accessibility settings.
Yes. Setting html { font-size: 62.5%; } makes 1rem equal 10px instead of 16px.
Any REM to EM converter must use 10 as the root font size input in this case, not 16. Using the wrong root value produces an incorrect EM output.
REM works better for global typographic scale systems and layout spacing. EM works better inside self-contained components where sizing should respond to the local font size.
Most production codebases use both: REM for the global scale, EM for component-internal proportions like padding and line height.
Join 28,000+ designers who get curated inspiration, tutorials, and hand-picked free resources every week.
No spam, ever. Unsubscribe with one click.