PX to EM Converter

What Is a PX to EM Converter?

A PX to EM converter translates fixed pixel values into scalable EM units, which are relative to the font size of their parent element. This matters a lot in responsive web design. A value like 24px stays exactly 24 pixels forever, but 1.5em scales with the user's settings or your layout's context, making it far more adaptable.

How the Conversion Works

The formula is straightforward:

1. Take your pixel value (e.g. 24px)
2. Divide it by the base font size (default: 16px)
3. The result is your EM value: 24 / 16 = 1.5em

Change the base font size if your project's root or parent element uses something other than the browser default of 16px. The tool recalculates everything in real time.

PX vs. EM: When to Use Which

EM units compound. If a parent is 1.2em and a child is also 1.2em, the child effectively becomes 1.44em relative to the root. Keep this in mind when nesting elements.

Why It Matters for Accessibility

Users can override font sizes in their browser settings. Layouts built with EM units respect those preferences. Pixel-based layouts do not. Using relative units is one of the simplest and most impactful things you can do to improve WCAG accessibility compliance.

Features of This Tool

• Bidirectional conversion - type in PX or EM and both fields update instantly
• Adjustable base size - match your project's actual root font size
• Live CSS output - copy a ready-to-use font-size declaration with one click
• Reference table - 10 common sizes converted at your current base, always in sync
• Base size warning - flags unusual values so you catch mistakes early

No sign-up. No ads. Just a fast, clean tool for front-end developers who want to stop doing mental arithmetic mid-project.

What Is the Difference Between PX and EM in CSS?

PX is an absolute unit. EM is relative to the font size of the element's direct parent. That single distinction changes how both units behave across devices, zoom levels, and nested elements.

With PX, font-size: 24px is always 24px, regardless of what the parent says.

With EM, font-size: 1.5em inside a parent set to 16px renders at 24px. Move that same element inside a parent set to 20px, and it renders at 30px. Same code, different output.

The compounding issue is the biggest reason people get EM wrong. A 1.5em child inside a 1.5em parent doesn't render at 1.5× root. It renders at 2.25× root, because each level multiplies.

Responsive design depends on this distinction. Around 90% of websites now use responsive layouts (BusinessDIT, 2024), and choosing between absolute and relative units is one of the foundational decisions behind that.

How EM Compares to REM

REM (root EM) is relative to the html element's font size, not the direct parent.

EM is relative to the current element's parent. It compounds through nested layers.

REM sidesteps the compounding problem entirely. A 2rem value always equals 2× the root font size, no matter how deeply nested it is.

When to use EM over REM:

• Padding and margin inside components that should scale with the component's font size

• Internal component spacing where proportional scaling is the goal

• Media queries where responding to user font preferences matters

When REM is the better call:

• Global typography settings

• Layout spacing that should stay consistent regardless of nesting depth

• Design systems like Bootstrap 5 and Material Design, which standardized on REM

What Is the Formula for Converting PX to EM?

The formula is: EM = Target PX ÷ Parent (or Base) Font Size in PX.

That's the whole thing. No shortcuts, no edge cases in the core math.

Worked examples:

• 24px ÷ 16px = 1.5em (default 16px base)

• 14px ÷ 16px = 0.875em

• 32px ÷ 16px = 2em

• 24px ÷ 20px = 1.2em (custom 20px base)

The reverse, converting EM back to PX, uses: PX = EM × Parent Font Size.

So 1.5em × 16px = 24px. Straightforward.

Where it gets tricky: font-size in CSS uses the parent's font size as the divisor, not the element's own computed size. Every other CSS property (padding, margin, width) uses the element's own font size as the reference point.

This is why you can write font-size: 1.5em; padding: 1em; on the same element and get different reference points for each property.

How Does Base Font Size Affect PX to EM Conversion?

The base font size is the denominator in every EM conversion. Change the base, and every EM value on the page changes with it.

By default, browsers set the base at 16px. That's what the html element inherits unless you override it.

3.08% of users browse with a non-default font size in their browser settings, according to Internet Archive research (Evan Minto, 2018). That's a larger share than the market share of browsers like Opera Mini.

Two common configurations:

• Default 16px: No override needed. Converters use 16 as the denominator.

• 62.5% trick: Setting html { font-size: 62.5%; } makes 1em = 10px. This simplifies mental math, since 14px becomes 1.4em instead of 0.875em.

Harry Roberts argues against the 62.5% approach because it forces you to explicitly re-declare every font size in the project. The simplicity comes at a cost.

Common Base Font Size Configurations

16px default (no override):

Standard browser behavior. The calculation stays clean for anyone using the default.

62.5% method:

Sets 1rem/1em to 10px, which makes conversion trivially easy. Used widely before REM adoption became standard. Chris Coyier of CSS-Tricks described a hybrid approach where root size is set in PX, module sizes use REM, and elements inside modules use EM for internal proportional scaling.

Custom design system bases (14px, 18px):

Enterprise UI kits sometimes set custom root sizes to fit their type scale. Atlassian Design System and some internal Material Design implementations use bases other than 16px.

Inline or inherited overrides:

If a parent component sets font-size: 20px, any EM values inside it calculate against 20px, not the root. This is the most common source of conversion errors.

PX to EM Conversion Table (Common Values)

The table below covers the most frequently converted values at 16px base and 10px base (62.5% method). Most projects use one or the other.

The values at 16px base look irregular because dividing by 16 rarely produces clean decimals. That's the main practical argument for the 62.5% trick.

Most common use cases for these values:

• 14px / 0.875em: Body copy in dense UIs (dashboards, data tables)

• 16px / 1em: Base body text, the most widely recommended minimum

• 18px / 1.125em: Comfortable reading size for long-form content

• 24px / 1.5em: Subheadings, UI labels

• 32px / 2em and above: Page headings, hero typography

Google's Material Design type scale uses 14sp and 16sp as body sizes, which map directly to these EM values when working in browser contexts. Over 50 million websites use Google Fonts for typography (Termageddon, 2024), meaning these size values appear across a significant share of the web.

When to Use EM Instead of PX in CSS

EM is the right choice when you want an element to scale proportionally with its surrounding text.

PX is the right choice when you want something to stay fixed regardless of text size.

Use EM for:

• padding and margin inside buttons and UI components, so they expand when the font size increases

• font-size in nested component structures where proportional scaling is intentional

• Media queries where the breakpoints need to respond to user font preferences, not just viewport dimensions

Use PX for:

• border-width and outline (decorative, should not scale)

• box-shadow (scaling shadows looks odd)

• Icon sizes tied to a grid, not to text

• Fine-grained spacing that must stay pixel-perfect regardless of context

WCAG 2.1 Success Criterion 1.4.4 requires text to be resizable up to 200% without loss of content or functionality. EM supports this natively because it responds to browser font size preferences. PX does not.

96.3% of the top one million home pages had detectable WCAG 2 failures in 2023 (WebAIM Million Report). Font sizing issues, including fixed PX sizes that don't respond to browser zoom or user preferences, are among the common contributors.

EM in Media Queries vs. PX in Media Queries

This is genuinely debated. In 2016, Zell Liew tested all three units in media queries across browsers and concluded that EM was the safest choice, particularly for users who change their browser's default font size.

PX-based media queries don't respond to browser font size changes. A user who bumps their default to 24px still triggers a PX breakpoint at the pixel width you specified, which can create layout mismatches at that user's preferred reading size.

Key behavior difference:

• @media (min-width: 40em) triggers at 640px for a user with a 16px default. For a user with a 20px default, it triggers at 800px. The layout adjusts to their reading preference.

• @media (min-width: 640px) always triggers at 640px, regardless of font preference.

Bootstrap 5 uses REM for breakpoints, not EM. The distinction matters because 1em in a media query always equals the browser's internal default (16px), not the overridden html font size. That makes EM and REM behave identically in media query contexts, which is worth knowing before you switch.

How to Convert PX to EM in CSS Manually

Manual conversion is a 4-step process. Converters automate all of it.

Step 1: Open Chrome DevTools (F12) and inspect the parent element. Check the "Computed" tab for its font-size value.

Step 2: Divide your target PX value by the parent's computed font size.

Step 3: Apply the resulting EM value in your CSS.

Step 4: Verify in the Computed tab that the resolved value matches what you expected.

Common places this goes wrong:

• Checking the root font size instead of the direct parent font size

• Forgetting that the font-size property divides against the parent's size, while padding divides against the element's own computed font size

• Using the 62.5% base calculation on a project that never set html { font-size: 62.5%; }

Here's a real scenario: you're styling a card component inside a sidebar. The sidebar has font-size: 14px set. You want the card's heading to be 20px. The correct EM value is 20 ÷ 14 = 1.429em, not 20 ÷ 16 = 1.25em.

One line to verify your result in CSS:

/* Target: 20px inside a 14px parent */
.card-heading {
  font-size: 1.429em; /* 14 × 1.429 ≈ 20px */
}

Responsive typography depends on getting this math right at every level of nesting. A single incorrect base assumption compounds through child elements and produces layouts that drift from the original design spec.

PX to EM Conversion in Design Tools

Design tools output pixel values. CSS needs EM. The handoff between those two environments is where most conversion work actually happens.

During Config 2023, Figma introduced Dev Mode with a unit conversion toggle. Inspecting any element in Dev Mode shows PX values converted to REM, assuming a 16px root. EM output specifically requires a third-party plugin since Figma treats EM and REM as equivalent when applying tokens to text layers (Tokens Studio documentation, 2024).

Figma to CSS Workflow

Figma's native Dev Mode converts PX to REM on inspection, not EM. The difference matters when working with nested components where the parent font size isn't the root.

The practical workaround:

• Design in PX inside Figma as usual

• In Dev Mode, toggle the unit dropdown to REM

• Note the REM value, then check the component's parent font size in code

• If the parent overrides the root, recalculate manually using the parent as the divisor

Tokens Studio for Figma supports both REM and EM token values and auto-converts to PX when applied to text layers in Design Mode.

Sass and PostCSS Automation

A Sass function handles EM conversion at the authoring level, before the browser ever sees the stylesheet.

@function em($px, $base: 16) {
  @return ($px / $base) * 1em;
}

.button {
  font-size: em(18);        /* 1.125em */
  padding: em(12) em(24);   /* 0.75em 1.5em */
}

PostCSS plugins run the conversion at build time on existing PX values. The postcss-pxtorem plugin converts PX to REM automatically; a similar EM-targeted plugin (postcss-px-to-em) applies the same logic using the parent font size as the denominator.

The advantage over manual conversion: the source CSS stays in PX (readable, designer-friendly), and the output file uses EM (accessible, scalable). Teams using a CSS Minifier or build pipeline can slot the PostCSS plugin into the same step.

Common Mistakes When Converting PX to EM

4 mistakes account for most EM conversion errors in real projects.

Wrong Base in the Calculation

The mistake: dividing by the root font size (16px) when the direct parent has an overriding font size.

A sidebar set to font-size: 14px changes the EM base for every child inside it. Calculating a child's font size against 16px instead of 14px produces a result that renders 14% larger than intended.

The fix: always check the computed parent font size in Chrome DevTools before calculating. The "Computed" tab shows the resolved PX value for font-size on any element.

EM Compounding in Nested Components

The compounding problem. A list item set to 1.2em inside a container also set to 1.2em renders at 1.44× the root, not 1.2×.

Modern CSS (2023) development confirmed native CSS nesting ships across all major browsers. That makes nesting more common, which makes accidental EM compounding more likely.

The safe approach: use REM for font sizes inside nested components unless compounding is intentional. Reserve EM for padding and margin within components where proportional scaling is the goal.

Applying the 62.5% Base Without Setting It

Quick to reproduce:

1. Developer reads an article recommending 10px as a mental math base

2. Calculates 14px ÷ 10 = 1.4em

3. Never adds html { font-size: 62.5%; } to the stylesheet

4. The browser uses the default 16px base

5. 1.4em renders as 22.4px instead of 14px

The 62.5% trick only works if the html selector explicitly sets it. Without it, the default 16px base applies and every EM value in the project is wrong.

Forgetting That font-size and padding Use Different Reference Points

font-size: 1.2em on an element uses the parent's font size as the base.

padding: 1.2em on the same element uses the element's own computed font size as the base.

Set both on a single element and they reference different numbers. This is per the CSS spec (MDN Web Docs), and it catches developers who assume EM always means "relative to the same thing."

PX to EM Conversion for Typography Specifically

Typography is where EM conversion gets the most use, and where the most specific rules apply.

Font size EM reference chain:

• html font size sets the root (default 16px)

• body or a parent element may override

• Each element's font-size in EM divides against the direct parent's computed size

• padding and margin in EM on that same element divide against its own computed font size

A working heading hierarchy at 16px base:

Type Scales and EM Multipliers

Type scales like Major Third (1.25 ratio) and Perfect Fourth (1.333 ratio) produce EM multipliers directly.

Major Third scale from 16px base:

• 16px = 1em

• 20px = 1.25em

• 25px = 1.5625em

• 31.25px ≈ 1.953em

These aren't clean numbers. That's why the 62.5% trick exists.

Google Fonts and Adobe Fonts both display PX values in their specimen pages. When fluid typography techniques use clamp() with EM bounds, those PX specimen values need manual conversion before the CSS works correctly.

Line-Height as a Special Case

line-height: 1.5em is relative to the element's own font-size, not the parent.

This is different from how font-size itself behaves. A 16px element with line-height: 1.5em gets a 24px line height, calculated against its own size.

The widely-used recommendation: set line-height as a unitless number (e.g., 1.5) rather than 1.5em. Both produce the same result, but the unitless version avoids confusing other developers who expect EM to reference the parent. Accessible typography guidelines consistently recommend a minimum line-height of 1.5 for body text, which maps to exactly 24px on a 16px base.

How Browsers Calculate EM Values

Browsers resolve EM to absolute PX during the layout pass, not the computed style pass.

MDN Web Docs and the CSS spec are clear on this: relative values like EM and percentages stay unresolved at the computed style stage. They convert to absolute PX during layout, once the browser knows the parent's actual dimensions and font size.

The rendering pipeline works like this:

1. CSSOM construction: browser parses CSS, builds the style tree

2. Computed styles: cascade and inheritance are resolved; EM stays as EM

3. Layout: relative units (EM, %) resolve to absolute PX using parent context

4. Paint and composite: final pixel values render to screen

What DevTools Shows

The DevTools "Computed" tab displays the resolved PX value, not the authored EM value.

A font-size: 1.5em declaration on a child of a 16px parent shows as 24px in the Computed tab. That's the used value after layout resolution.

Useful for debugging:

• Check the parent element's Computed font-size to verify the base before calculating

• Compare Computed values at different zoom levels to confirm EM scales correctly

• Use the Computed tab on the html element to see the actual root size, regardless of what the stylesheet declares

Browser Zoom and EM Behavior

Page zoom (Ctrl/Cmd + mouse wheel) scales the entire rendered page. Both PX and EM values appear larger because the browser multiplies the device pixel ratio.

Text-only zoom (Firefox: View > Zoom > Zoom Text Only) increases font sizes without scaling layout. EM values scale with this because they are tied to font size. PX values on non-font properties do not.

WCAG 2.1 SC 1.4.4 requires text to be resizable to 200% without loss of function. Chrome 120+, Firefox 121+, and Safari 17+ all handle EM inheritance identically per the CSS spec, meaning a properly EM-based layout passes this criterion in all three. Sites using PX for font sizes often fail it, which is part of why web accessibility audits flag fixed-unit typography as a recurring issue. WebAIM's 2023 Million report found 96.3% of the top one million homepages had detectable WCAG failures.

FAQ on Px To Em Converter

What is the formula for px to em conversion?

Divide the target pixel value by the parent element's font size. With the browser default of 16px, 24px becomes 1.5em. If the parent is set to 20px, that same 24px becomes 1.2em instead.

What is 1em in pixels?

1em equals 16px by default, since all major browsers set the root font size to 16px unless overridden. Change the base font size on the html or parent element, and the resolved pixel value changes with it.

Why use em instead of px in CSS?

EM scales with user font preferences and browser zoom settings. PX stays fixed. For responsive typography, padding inside components, and accessible font sizing, EM is the more flexible choice. WCAG 2.1 requires text to resize to 200% without loss of function.

What is the difference between em and rem?

EM is relative to the direct parent element's font size. REM is relative to the root html element. EM compounds through nested layers; REM does not. Use REM for global type, EM for component-scoped scaling.

How do I convert px to em in Figma?

Figma's Design Mode outputs PX only. In Dev Mode (introduced at Config 2023), a unit dropdown converts values to REM automatically, assuming a 16px root. For EM specifically, the Tokens Studio plugin handles the conversion within design token workflows.

What happens when em values are nested?

They compound. A 1.5em child inside a 1.5em parent renders at 2.25× the root size, not 1.5×. Each level multiplies by its parent's computed font size. This is the most common source of unexpected sizing in nested CSS components.

Is px or em better for media queries?

EM handles user font preference changes; PX does not. A 40em breakpoint triggers at different viewport widths depending on the user's browser font setting. Zell Liew's testing showed EM as the more accessible choice, though the debate continues among developers.

How does the 62.5% base font size trick work?

Setting html { font-size: 62.5%; } makes 1em equal 10px, which simplifies mental math. 14px becomes 1.4em instead of 0.875em. The downside is that every font size in the project must be redeclared, since the base drops from 16px to 10px.

Does Google care whether you use px or em for font sizes?

Google's ranking systems don't penalize PX directly. However, sites using fixed PX font sizes often fail WCAG 2.1 accessibility criteria, which can affect usability signals. Core Web Vitals and accessibility compliance both factor into how pages are evaluated.

What tools convert px to em automatically?

Several options exist: standalone web converters, the VS Code extension "px to rem & rpx & vw" by cipchk, the PostCSS plugin postcss-px-to-em, and Sass functions written directly into the build step. The CSS Clamp Calculator handles fluid type ranges using the same base-relative math.