- Design Resources
- Inspiration
- Web Design
- Logos
- Graphic Design
- UI Design
- UX
- Advertising
- Motion graphics
- Infographics
- Wallpapers
- Various
- About Us
- Contact
Convert between em and px units instantly. Set your base font size and get accurate results with a ready-to-use CSS snippet.
Common em values and their pixel equivalents
| EM | PX | Common Use |
|---|
This EM to PX converter takes the guesswork out of CSS unit conversion, giving you instant, accurate results based on any base font size.
In CSS, em is a relative unit. It scales relative to the font size of the element's parent. That makes it powerful for fluid, scalable layouts, but tricky to reason about in absolute terms. This tool bridges that gap.
The formula is simple:
So 1.5em at a 16px base equals 24px. Change the base and everything updates instantly.
16px.| Unit | Scales with font size? | Best for |
|---|---|---|
em | Yes | Typography, spacing, responsive components |
px | No | Borders, shadows, fixed layouts |
rem | Yes (root only) | Global spacing, accessible type scales |
A good rule: use em or rem for anything that should adapt to user preferences. Use px when you need something fixed and predictable.
The base font size is everything. 1em at 16px is 16px. At 20px, it becomes 20px. If your project overrides the root font size, your conversions will be wrong unless you account for it. That is what the base input is for.
Use the reference table in the tool above for a full breakdown.
An EM to PX converter is a calculation tool that takes an em value and a base font size as inputs, then returns the equivalent pixel value.
It's used by front-end developers and designers who work in CSS but need to verify exact pixel output at specific base sizes. Without it, you're doing mental math every time you touch a stylesheet.
The core inputs: em value + parent (or root) font size in pixels.
The output: a resolved pixel measurement the browser would compute at render time.
It's useful when inheriting a codebase with em-heavy typography and you need to understand what's actually rendering on screen. Or when a designer hands you a pixel-based spec and you need to write it in em units.
Design handoff: Figma works entirely in pixels. If your CSS uses em units, a converter closes the gap between the spec and the stylesheet.
Debugging: Chrome DevTools shows computed pixel values in the Styles panel. A converter helps you verify those values match your em declarations before touching the browser.
Responsive typography: When building fluid type scales using CSS clamp(), you often need to know the pixel equivalent at minimum and maximum breakpoints.
The converter is a point-in-time tool. It answers "what does this em value equal right now, with this base size?" It doesn't replace understanding the cascade.
The formula is: PX = EM × Parent Font Size.
One em multiplied by the parent element's font size in pixels. That's it.
If the parent has a font size of 16px and you're working with 1.5em, the result is 24px. Change the parent to 20px, and the same 1.5em becomes 30px.
The converter doesn't assume a fixed base. It requires both inputs because the pixel equivalent of any em value changes with the context.
PX is an absolute CSS length unit. EM is a relative unit calculated against the nearest parent element's font size.
PX renders at the same size regardless of inherited or user-defined font preferences. EM scales up or down depending on whatever font size has been declared on the parent element. This single difference has real consequences for responsive design and accessibility.
The Web Almanac (HTTP Archive, 2024) found px is used for font sizing on 65% of desktop pages and 66% of mobile pages. EM accounts for 9% of font-size usage, up from 6% in 2022.
|
Unit |
Type |
Reference Point |
Scales with Browser Prefs |
|---|---|---|---|
|
px |
Absolute |
Fixed screen pixel |
No |
|
em |
Relative |
Parent element font size |
Yes |
|
rem |
Relative |
Root ( |
Yes |
|
% |
Relative |
Parent element |
Yes |
Every browser rendering engine (Blink in Chrome and Edge, Gecko in Firefox, WebKit in Safari) resolves em units during the layout phase.
The process: find the closest ancestor with an explicit font-size declaration, multiply the em value by that size, output the computed pixel value.
What makes this tricky: if no ancestor has an explicit font size, the browser falls back to its own default, which is 16px across all major browsers (Chrome, Firefox, Safari, Edge) by the W3C CSS specification.
So 1em on a bare <p> with no parent styling = 16px. The same 1em inside a <div> with font-size: 20px = 20px.
The cascade decides the reference. The converter can only be accurate when you know what the parent's font size actually is.
When a user sets their browser's default font size to 20px (common among users with low vision), CSS em and rem units respond to that change.
PX values do not.
MDN Web Docs notes directly: "Defining font sizes in px is not accessible, because the user cannot change the font size in some browsers."
The Web Almanac 2024 data showing 65% of desktop pages still using px for font sizes reflects how widespread this accessibility gap remains.
The EM to PX conversion formula is: PX = EM value × Parent font size (in pixels).
No other variables. The output changes only when one of these two inputs changes. At the default browser font size of 16px, 1em = 16px, 1.5em = 24px, 2em = 32px, and 0.875em = 14px.
MDN confirms: "by default 1em is equivalent to 16px, and 2em is equivalent to 32px."
The table below covers the most commonly used em values across 4 base sizes. Designers working in Figma (px) most often need the 16px column, since that matches the browser default.
|
EM Value |
Base 14px |
Base 16px |
Base 18px |
Base 20px |
|---|---|---|---|---|
|
0.5em |
7px |
8px |
9px |
10px |
|
0.75em |
10.5px |
12px |
13.5px |
15px |
|
0.875em |
12.25px |
14px |
15.75px |
17.5px |
|
1em |
14px |
16px |
18px |
20px |
|
1.25em |
17.5px |
20px |
22.5px |
25px |
|
1.5em |
21px |
24px |
27px |
30px |
|
2em |
28px |
32px |
36px |
40px |
|
3em |
42px |
48px |
54px |
60px |
The 16px column is the one you'll use 90% of the time. The others matter when someone has set font-size: 62.5% on the <html> element (more on that in the next section).
The converter takes 2 inputs and runs the multiplication formula once.
Input 1: The em value (e.g., 1.25).
Input 2: The base font size in pixels (default field value is usually 16px).
Output: The resolved pixel value.
Most online converters run the calculation in real time as you type. No submit button needed.
Not every em value is clean. Here's what happens at the edges:
Decimal inputs like 0.875em are valid. At 16px base, 0.875 × 16 = 14px exactly.
Very small values like 0.25em = 4px at 16px base. Browsers will render this, but it produces near-invisible text.
Large values like 5em = 80px at 16px. Technically valid, rarely used for font size.
Decimal outputs like 1.3em at 16px base = 20.8px. Browsers handle sub-pixel rendering differently. Chrome and Firefox use anti-aliasing; Safari rounds in some cases.
Zero input resolves to 0px. Valid in CSS (font-size: 0 hides text).
The converter itself doesn't round. What the browser does with a 20.8px computed value depends on the rendering engine and display density.
All major browsers (Chrome, Firefox, Safari, Edge) set the <html> element's font size to 16px by default. This comes from the W3C CSS specification.
A bare page with no CSS applied renders body text at 16px. Any em-based value on an unstyled element uses 16px as its reference.
That said, the actual parent font size in a real stylesheet can be anything. The 16px default is a starting point, not a constant.
The root font size is the font-size declared on the <html> element. It is 16px by default in all major browsers.
Changing it changes the pixel output of every em and rem value on the page. This is where most EM to PX conversion errors come from.
A common pattern sets html { font-size: 62.5%; }, which resolves to 10px (62.5% of 16px).
The reason: 1rem or 1em now equals 10px, making the math simpler. 1.4rem = 14px, 1.6rem = 16px. No mental gymnastics.
The catch: every em-based calculation on the page now uses 10px as the base, not 16px. Run a converter assuming 16px on a page using this pattern and every output will be wrong.
Tailwind CSS does not use this pattern. Its default spacing and typography scale uses rem, referenced against the standard 16px root. PostCSS plugins like postcss-pxtorem let you configure the root value explicitly when converting at build time.
3 ways to check the real computed root font size:
Chrome DevTools: Open the Elements panel, select the <html> element, click Computed in the Styles pane. Look for font-size.
JavaScript: parseFloat(getComputedStyle(document.documentElement).fontSize) returns the resolved value in px.
CSS reset inspection: Check if the project uses Normalize.css or a custom reset that overrides the root font size.
The converter is only accurate when the base size input matches the real parent or root font size. Getting that number wrong makes the output useless.
EM and REM use the same formula (value × base size), but they reference different elements.
EM references the nearest parent element's font size. REM always references the <html> root element's font size. Same math, different anchor point.
At the top level of a flat document with no nested font sizes, 1em and 1rem both equal 16px. They diverge inside nested elements.
Consider a component where the parent <div> has font-size: 20px:
A child with font-size: 1.5em = 30px (1.5 × 20px parent)
A child with font-size: 1.5rem = 24px (1.5 × 16px root)
Same declaration, 6px difference. That gap widens with deeper nesting.
The compounding problem is specific to em. DevPik (2026) describes it clearly: "1.2em inside 1.2em equals 1.44× the grandparent's size." Each nested level multiplies the parent. REM doesn't do this because it always goes back to the root.
This is why most design systems (including Tailwind CSS and Bulma) default to rem for global sizing. EM gets used for component-scoped scaling where proportional growth relative to the component's own text size is the actual goal.
|
Scenario |
Use EM |
Use REM |
|---|---|---|
|
Button padding scaling with button text |
Yes |
No |
|
Global heading sizes |
No |
Yes |
|
Media query breakpoints |
No |
Yes (consistent) |
|
Spacing inside a self-contained component |
Yes |
Optional |
|
Body font size |
No |
Yes |
Converting PX to EM and PX to REM require the same formula. The choice of which unit to write into your CSS depends on whether you want the value anchored to the parent or the root.
If you need to go in the other direction, the REM to PX converter works the same way, using the root font size as the base instead of the parent.
EM units appear across 4 main CSS property categories: typography, spacing, media queries, and component-level scaling.
Each use case relies on the same calculation logic, but the reasoning behind choosing em over px differs by context.
Font size is the most common em use case. Set font-size: 1.25em on a heading inside a component, and the heading scales proportionally when the component's base font size changes.
Leading (line height) and tracking (letter spacing) also use em frequently. A line-height: 1.5em on a paragraph means the line height is always 1.5× the current font size, regardless of what that size is. This keeps vertical rhythm intact across different screen sizes without recalculating.
Typographic hierarchy in design systems often uses em for relative size relationships within a component and rem for absolute sizes across the page.
Component padding with em:
When a button has padding: 0.75em 1.5em, the internal spacing scales with the button's font size.
Increase the button's font size from 14px to 18px, and the padding grows proportionally. The button doesn't become cramped or exaggerated. This is the main advantage em spacing has over px.
Where px still wins: borders, box shadows, and grid gutters. These don't need to scale with text size, and fixed pixel values keep them visually stable across different type sizes.
Users with low vision often increase their browser's default font size from 16px to 20px or 24px.
CSS px values ignore this. EM and rem values respond to it.
Web.dev states directly: "By sizing text with relative units like em or rem, rather than an absolute unit like px, the size of your text can respond to user preferences."
The Web Almanac 2024 data shows 65% of desktop pages still use px for font sizes, meaning the majority of websites don't scale with user font preferences. EM usage grew from 6% to 9% between 2022 and 2024, but adoption of accessible font units remains slow.
WCAG 2.1 Success Criterion 1.4.4 requires text to be resizable up to 200% without loss of content or functionality. Using px for font sizes creates a direct conflict with this requirement.
Most EM to PX conversion errors come from one source: assuming the base font size without checking it.
The computed pixel value is only correct if the base size input matches the actual parent or root font size in the live CSS. Get that wrong, and every calculation in the stylesheet is off.
|
Mistake |
Why It Happens |
Result |
|---|---|---|
|
Assuming 1em = 16px always |
Ignoring CSS resets or parent overrides |
Wrong px output |
|
Confusing em with rem |
Different reference points |
Errors in nested elements |
|
Ignoring the 62.5% hack |
Common pattern, changes base to 10px |
Every conversion is wrong |
|
Rounding decimal px |
Sub-pixel values ignored |
Layout drift on non-retina screens |
The default is 16px, but it's not guaranteed.
If a project uses html { font-size: 62.5%; }, the effective base is 10px, not 16px. Running 1.4em through a converter at 16px gives 22.4px. The real rendered value is 14px.
This pattern is common enough that it trips up developers working on inherited codebases regularly. Always check the <html> element's computed font size in Chrome DevTools before trusting any conversion output.
EM compounds with nesting. REM does not.
A child set to 1.2em inside a parent that's already 1.2em renders at 1.44× the grandparent's size, per DevPik (2026). Run that same value through a flat converter at root size and you get the wrong number.
The converter isn't broken. The context is just more complex than a flat calculation handles. Use the actual parent's computed font size as the base input, not the root value.
Decimal px values like 20.8px or 13.5px exist in the math but get handled differently by rendering engines.
Chrome and Firefox apply anti-aliasing to sub-pixel values
Safari rounds in some display contexts
On 1x (non-retina) screens, sub-pixel differences can cause hairline gaps between elements
When precision matters at component boundaries, round your em values to produce clean px outputs. 0.875em at 16px = 14px exactly. That's cleaner than 0.9em = 14.4px.
3 methods work for EM to PX conversion directly in code: manual formula application, CSS calc(), and JavaScript's getComputedStyle.
Each fits a different scenario. The manual method is for authoring. calc() is for dynamic CSS. JavaScript is for runtime verification.
CSS calc() lets you write the multiplication directly in the stylesheet.
.heading {
font-size: calc(1.25 * 16px); /* = 20px */
}
This works when the base size is known and fixed. It makes the intent explicit in the code: the developer is showing the em-to-px relationship without losing the connection to the base value.
Pair with CSS custom properties for a cleaner approach:
:root {
--base-font: 16px;
}
.label {
font-size: calc(0.75 * var(--base-font)); /* = 12px */
}
Change --base-font once and every calc() instance updates. No converter needed.
getComputedStyle returns the browser's resolved pixel value for any element.
const fontSize = parseFloat(
getComputedStyle(document.documentElement).fontSize
);
// Returns the actual root font size in px
For a specific element:
const el = document.querySelector('.my-component');
const resolvedSize = parseFloat(getComputedStyle(el).fontSize);
This is the most reliable method for verifying what the browser actually renders, especially on pages where the root font size has been overridden. MDN documents getComputedStyle() as returning resolved values after all cascade rules are applied.
No code needed. Just 3 steps:
Open DevTools (F12)
Select the element in the Elements panel
Click the Computed tab in the right pane
The font-size value shown there is the resolved pixel value. It reflects the actual cascade: inheritance, resets, and all.
This is how most developers verify em-to-px output in practice. Faster than writing JavaScript, and the result is definitive.
Design tools and CSS build tools handle the em/px relationship differently. Most work in pixels natively and require manual unit translation when writing CSS.
Figma is the clearest example: all spacing, font sizes, and layout values in Figma are expressed in pixels. There's no em or rem in the design spec. The conversion to em units happens entirely on the developer's side.
Both Figma and Sketch output pixel values in their inspect panels.
A designer sets a heading at 24px in Figma. The developer sees 24px in Dev Mode. Converting that to em (24 ÷ 16 = 1.5em) is the developer's responsibility, not the tool's.
This is why having a reliable PX to EM converter is part of standard front-end workflow. The design-to-code gap on unit types is consistent and predictable. It just requires the conversion step every time.
Builder.io's Visual Copilot (a Figma-to-Tailwind plugin) partially automates this, but it generates rem, not em, by default because rem is more predictable at scale.
PostCSS plugins like postcss-pxtorem automate unit conversion at build time.
How it works: write your CSS in px during development, and the plugin converts specified properties to rem before the stylesheet reaches the browser.
The config matters: the plugin requires a rootValue setting (default 16) that must match the actual root font size. Set it wrong and every output is incorrect, just like a manual converter with a bad base.
postcss-pxtorem converts to rem specifically, not em. For em output at build time, postcss-em is the alternative, but it requires knowing the parent context for each declaration.
px to rem & rem to px (one of the top CSS extensions on the VS Code marketplace) provides hover tooltips and inline conversion directly in the editor.
It doesn't handle em specifically in most configurations, since em's context-dependency makes automated conversion unreliable without knowing the parent font size. Most VS Code CSS tools default to rem for that reason.
For a fast cross-unit reference, tools like the Type Scale Generator and REM to EM converter cover the common conversions front-end developers hit repeatedly during stylesheet authoring.
Choosing between em and px for font sizes has a direct, measurable impact on users who rely on browser font size preferences.
The core issue: px values are fixed. They do not respond when a user sets their browser's default font size to 20px or 24px. EM and rem values scale proportionally with that preference.
WCAG 2.1 Success Criterion 1.4.4 requires that text can be resized up to 200% without loss of content or functionality.
Using px for font-size creates a direct conflict with this requirement in browsers where zoom and text scaling behave differently. Users who increase only the text size (not the full page zoom) see no change when font sizes are set in px.
About 12% of the American population over 40 has moderate to severe vision impairment (Pew Research Center), making browser font scaling a real, frequently used accessibility tool, not an edge case.
The Web Almanac 2024 data is direct: 65% of desktop pages use px for font sizing.
That number hasn't moved significantly since 2022. The likely reasons:
Pixel-based design tools (Figma, Sketch) produce px values, creating friction at handoff
Developers familiar with px from pre-responsive workflows continue using it
CSS resets and frameworks sometimes lock in px values at the base level
EM usage grew from 6% to 9% between 2022 and 2024 (HTTP Archive). Slow, but moving in the right direction.
Google's Material Design system uses rem for all typographic sizing, which scales with the root font size.
Tailwind CSS defaults to rem as well. Its text-base class computes to 1rem (16px at default), and all type scale classes (text-sm, text-lg, etc.) are rem-based. Users who increase their browser font preference see the full Tailwind type scale adjust proportionally.
Em-based spacing within Tailwind components (like button padding) scales with the component's own font size, keeping proportions correct even when the base changes. This combination (rem for global sizing, em for component-scoped spacing) represents current best practice in accessible web design.
The EM to PX converter is most useful in responsive workflows when building type scales, converting design specs, and calculating em-based breakpoint values.
More than 60% of web traffic comes from mobile devices (Medium, 2024), which makes accurate em-to-px conversion at multiple base sizes a practical necessity, not a nice-to-have.
Figma specs use px. Responsive CSS uses em or rem. The converter bridges the two.
Workflow:
Get px values from Figma's inspect panel
Input each into the converter with the project's root font size as the base
Write the resulting em values into the stylesheet
A heading specified at 32px in a project with an 18px base font becomes 1.778em. Not obvious without a calculator, and rounding to 1.75em gives 31.5px, close enough for most layouts but worth knowing the actual figure.
For the reverse conversion, the PX to EM converter handles Figma-to-CSS translation directly.
Media queries written in em units respond to the browser's base font size, not just the viewport width.
@media (min-width: 48em) equals 768px at the default 16px base. But at a 20px user-set base, that same query triggers at 960px.
This behavior is intentional for accessibility: if a user has increased their font size, the layout reflow happens at a larger viewport width, giving the larger text more room. SitePoint notes that rem and em in media queries always reference the browser-set font size, not any CSS override on the root element.
The converter helps calculate these breakpoints accurately. Input the em value, set the base to match the browser default (16px for most users), and get the expected trigger width.
A consistent typographic scale uses multipliers from a single base size.
Example scale at 16px base:
0.75em = 12px (small labels, captions)
0.875em = 14px (secondary text)
1em = 16px (body)
1.25em = 20px (lead paragraph)
1.5em = 24px (H3)
2em = 32px (H2)
3em = 48px (H1)
The converter confirms each value before it goes into the stylesheet. Combined with tools like the Type Scale Generator, you can build and verify a full typographic hierarchy without guessing at pixel equivalents.
For related unit conversions across the same workflow, the EM to REM converter handles the translation between the two relative units when switching from parent-relative to root-relative sizing.
CSS clamp() brings em and px together for fluid typography. The function takes 3 arguments: minimum size, preferred size (viewport-relative), and maximum size. The preferred value is usually in vw, but the min and max are often in rem or em. LogRocket (2025) notes that clamp() for scalable typography eliminates the need for multiple media query breakpoints for font size adjustments, letting the converter verify the em/px boundaries directly.
Multiply the em value by the parent element's font size in pixels. PX = EM × Parent Font Size. At the browser default of 16px, 1.5em equals 24px. The result changes whenever the parent font size changes.
At the default browser font size of 16px, 1em equals 16px. Change the parent element's font size to 20px, and 1em becomes 20px. The pixel value is never fixed — it depends entirely on the inherited font size.
The base font size input is probably wrong. Check if the project uses html { font-size: 62.5%; }, which sets the base to 10px instead of 16px. Always verify the actual computed font size in Chrome DevTools before converting.
Both use the same formula. Em references the nearest parent element's font size. Rem always references the root <html> element. In nested components, they produce different pixel values. A REM to PX converter handles rem calculations separately.
Divide the pixel value by the parent font size. If the parent is 16px and you need 24px, the em value is 1.5em (24 ÷ 16). Use a PX to EM converter to speed this up during stylesheet authoring.
Yes. Unlike px, em units respond to user-defined browser font preferences. If a user sets their default browser font to 20px, all em-based values scale accordingly. This makes em the better choice for accessible, responsive typography that meets WCAG 1.4.4 requirements.
At a 16px base, 0.875em equals 14px (0.875 × 16). At a 14px base it equals 12.25px. This value appears frequently in CSS type scales as the small text size, sitting just below the 16px body font default.
Use rem for global font sizes across the page. Use em for component-level sizing where spacing should scale relative to the component's own text size, such as button padding. Most design systems including Tailwind CSS follow this pattern by default.
Open Chrome DevTools, select the element, and click the Computed tab. The font-size shown is the resolved pixel value after all CSS cascade rules apply. You can also run parseFloat(getComputedStyle(element).fontSize) in the browser console for any element.
Em in media queries always references the browser's base font size, not any CSS override. @media (min-width: 48em) equals 768px at the 16px browser default. This makes em-based breakpoints scale with user font preferences, unlike px-based breakpoints.
Join 28,000+ designers who get curated inspiration, tutorials, and hand-picked free resources every week.
No spam, ever. Unsubscribe with one click.