- Design Resources
- Inspiration
- Web Design
- Logos
- Graphic Design
- UI Design
- UX
- Advertising
- Motion graphics
- Infographics
- Wallpapers
- Various
- About Us
- Contact
Enter a value in either field. Click any row in the table to load it.
This PX to EM converter lets you instantly switch between pixel and EM values without doing the math yourself. Type in either field, adjust the base font size, and the result updates in real time.
Pixels are fixed. EMs are relative to the parent element's font size, which makes them useful for components that need to scale proportionally. Change the base and everything scales with it.
The conversion is straightforward:
em = px / base font sizepx = em x base font sizeThe default base is 16px, which is what most browsers use. If your project sets a different root font size, update the base field accordingly.
| Pixels (px) | Em (em) | Typical use |
|---|---|---|
| 12px | 0.75em | Small labels, captions |
| 14px | 0.875em | Secondary text, UI elements |
| 16px | 1em | Body text (browser default) |
| 20px | 1.25em | Lead paragraphs, subheadings |
| 24px | 1.5em | H3 headings |
| 32px | 2em | H2 headings |
| 48px | 3em | H1, hero text |
EM is relative to the parent element. This can compound in nested components, which is sometimes surprising. REM (root EM) is always relative to the <html> element, making it more predictable for global typography. For component-level spacing, EM gives you more local control. For font sizes across a whole page, REM is usually the safer choice.
Learn more about CSS units in the MDN documentation on CSS values and units.
A PX to EM converter is a tool that calculates the EM equivalent of any pixel value using a defined base font size.
The default base in every major browser is 16px, which means 1em = 16px by default. Change that base, and every output changes with it.
The formula is fixed: EM = PX ÷ Base Font Size. So 24px at a 16px base gives you 1.5em. At a 20px base, that same 24px becomes 1.2em.
Most converters accept a custom base input. This matters because components, cards, and nested elements often have their own font-size overrides that change what the base actually is in practice.
The output goes directly into CSS. No rounding, no guessing.
Browser default: 16px, set by the html element unless explicitly overridden.
Every browser ships with this default. Most sites don't change it, which is why 16px is the reliable starting assumption for most PX to EM conversions.
If a stylesheet sets html { font-size: 18px; }, every EM-based value across the page recalculates against 18, not 16.
Some teams change the root font size intentionally. A common developer trick is setting html { font-size: 62.5%; }, which makes 1rem equal 10px and simplifies mental math (noted by CSS-Tricks' Chris Coyier as one of the most debated patterns in CSS unit strategy).
Using a converter with the wrong base produces values that look correct but compute incorrectly in the browser. Chrome DevTools' Computed tab shows the real rendered value, making it the fastest way to verify output.
PX is a fixed, absolute CSS unit. EM is a relative unit tied to the font size of the nearest parent element.
That single difference drives every layout and accessibility decision that follows.
PX ignores user preferences. If someone sets their browser font size to 20px for readability, PX-based text stays exactly where it was. EM-based text scales with them.
According to the 2024 Web Almanac (HTTP Archive), 65% of desktop pages and 66% of mobile pages still use PX for font sizes, while EM is used on just 9% of pages. The gap shows how slowly the industry has moved toward accessible units despite the clear benefit of relative sizing.
|
Unit |
Type |
Relative To |
Scales With Browser Settings |
|---|---|---|---|
|
PX |
Absolute |
Nothing (fixed) |
No |
|
EM |
Relative |
Parent element font size |
Yes |
|
REM |
Relative |
Root (html) font size |
Yes |
|
% |
Relative |
Parent element |
Yes |
EM values multiply through nested elements. That's the part most developers get wrong the first time.
If a parent has font-size: 1.5em and a child also has font-size: 1.5em, the child's computed size is 2.25× the base, not 1.5×.
Each EM value is resolved against the computed font size of its direct parent, not the root. So nesting two 1.5em elements inside each other at a 16px base gives 16 × 1.5 × 1.5 = 36px computed.
This compounding is useful for self-scaling components. It becomes a problem when developers apply EM without checking what the actual parent font size is.
Media queries are where the PX vs EM difference becomes most visible.
EM-based media query breakpoints respond to the browser's base font size. A breakpoint written as @media (min-width: 48em) fires at 768px when the base is 16px, but at 960px if the user has set their browser font size to 20px.
PX-based breakpoints @media (min-width: 768px) fire at the same pixel point regardless of user font settings.
Zell Liew's 2016 analysis (still widely cited in CSS communities) found that EM-based media queries handle user font size changes and browser zoom states more reliably than PX-based ones. The behavior difference is particularly relevant for users who rely on large default font sizes for readability.
The formula for converting PX to EM is: EM = PX Value ÷ Parent Element Font Size (in PX).
That's the whole thing. No multipliers, no correction factors.
Example: 24px ÷ 16px = 1.5em. If the parent has font-size: 20px, the same 24px becomes 24 ÷ 20 = 1.2em.
The base input isn't always 16. That's the most common conversion mistake. Before using any converter, confirm the actual computed font size of the parent element in browser DevTools.
When converting values inside a component, the base changes to that component's font size.
Say a card has font-size: 20px. All internal spacing and text values convert using 20 as the divisor, not 16. A padding of 16px inside that card becomes 16 ÷ 20 = 0.8em.
Precision rule: Round to 4 decimal places maximum. 1.3125em is correct. Longer decimals add no accuracy and clutter the stylesheet.
Not all PX values divide evenly into EM.
Some produce clean numbers: 16px ÷ 16 = 1em, 24px ÷ 16 = 1.5em. Others produce repeating decimals: 13px ÷ 16 = 0.8125em.
The CSS specification handles these without rounding errors. Browsers compute the final pixel value from the EM value, so 0.8125em × 16px = 13px resolves correctly. Developers occasionally round aggressively (e.g., 0.81em) and wonder why their spacing is off by a pixel.
The table below covers the most commonly needed values at a 16px base. These are the numbers developers look up most, from body text to display headings.
|
PX Value |
EM at 16px base |
EM at 14px base |
EM at 18px base |
|---|---|---|---|
|
10px |
0.625em |
0.7143em |
0.5556em |
|
12px |
0.75em |
0.8571em |
0.6667em |
|
14px |
0.875em |
1em |
0.7778em |
|
16px |
1em |
1.1429em |
0.8889em |
|
18px |
1.125em |
1.2857em |
1em |
|
20px |
1.25em |
1.4286em |
1.1111em |
|
24px |
1.5em |
1.7143em |
1.3333em |
|
32px |
2em |
2.2857em |
1.7778em |
|
48px |
3em |
3.4286em |
2.6667em |
|
64px |
4em |
4.5714em |
3.5556em |
Why three base columns? A 14px base is common in dense UI frameworks and admin interfaces. An 18px base shows up in accessibility-focused designs and editorial sites that prioritize reading comfort.
Some conversions produce clean, memorable EM numbers. Others don't.
Clean conversions at 16px base:
8px = 0.5em
16px = 1em
24px = 1.5em
32px = 2em
48px = 3em
Recurring decimals: 10px (0.625em), 14px (0.875em), 18px (1.125em). These are perfectly valid but worth using a converter for rather than calculating by hand.
A PX to EM converter needs 2 inputs: the PX value to convert, and the base font size of the relevant parent element.
Getting the second input wrong is the most common error. Most people default to 16 without checking.
Steps for accurate conversion:
Identify the CSS property being converted (font-size, padding, margin, etc.)
Find the computed font size of the parent element in browser DevTools
Enter that computed size as the base
Apply the output EM value to the correct CSS property
Verify the rendered output in DevTools' Computed tab
Open Chrome DevTools or Firefox Developer Tools, select the parent element, and click the Computed tab.
Look for the font-size row. That number is the actual base to use, regardless of what the stylesheet says. Inheritance, resets, and framework defaults all factor into the computed value.
Common base font sizes by context:
Default browser: 16px
Bootstrap 5: 16px (set on the body element)
Tailwind CSS: 16px root default
Dense UI / admin dashboards: 13–14px
Editorial / accessibility-focused: 18–20px
Tailwind CSS, for example, ships with a 16px root by default but makes it easy to override via the theme.fontSize config. Any override requires a new base calculation before converting.
EM units are useful in 4 specific CSS contexts: typography, component-internal spacing, padding relative to text size, and media query breakpoints.
Outside those 4, PX usually makes more sense.
The 2024 Web Almanac data confirms that EM adoption has grown from 6% to 9% of pages between 2022 and 2024, but 65% of pages still use PX for font sizes even though relative units give users more control. The slow shift reflects how long it takes for new practices to reach production codebases.
Best use cases:
font-size on text elements inside a self-contained component
line-height relative to the text size it's paired with
letter-spacing proportional to font size
padding and margin that should scale when the component's font size changes
The key benefit: when a component's root font-size changes, every internal EM value scales proportionally. No need to update padding, margin, or text size individually.
Airbnb's design system uses this pattern for card components where spacing relationships need to hold at multiple size variants.
EM-based breakpoints outperform PX in one specific scenario: when users change their browser's default font size.
A breakpoint written as @media (min-width: 48em) evaluates to 768px at the default 16px base. For a user with a 20px base font size set in their browser, that same breakpoint fires at 960px, giving them a layout better suited to their larger text.
Properties where EM works well:
font-size
line-height
padding (when tied to text size)
margin (in typographic context)
Media query breakpoint widths
Properties where PX is better:
border-width
box-shadow offsets and blur radius
Icon dimensions fixed to a pixel grid
border-radius on containers (unless intentionally scaling)
Over 2.2 billion people worldwide have vision impairments (WHO, 2026), and many adjust browser font settings as a baseline accessibility tool. CSS units that respect those settings directly affect whether your layout holds up for that audience.
EM is relative to the font size of the nearest parent element. REM is relative to the font size of the root html element, always.
That's the only difference. But it's a significant one in practice.
|
EM |
REM |
|
|---|---|---|
|
Relative to |
Nearest parent |
Root (html) element |
|
Compounding |
Yes, accumulates through nesting |
No, always resets to root |
|
Best for |
Component-internal scaling |
Global layout and spacing |
|
Predictability |
Lower in deep nesting |
Higher, always consistent |
REM stands for "root em." It resolves against the html element's font size, not the parent's.
1rem equals 16px when the root is 16px. Always. Whether the element is nested 1 level or 10 levels deep.
EM doesn't behave this way. Nesting font-size: 1.5em through 3 levels gives 16 × 1.5 × 1.5 × 1.5 = 54px computed. This is sometimes intentional for typographic scaling systems. Usually it's a bug.
Use REM for:
Global font sizes across the page
Site-wide spacing (margins, paddings not tied to local text)
Layout dimensions that should stay consistent regardless of component context
Use EM for:
Spacing inside a component that should scale with the component's local font size
Button padding that should stay proportional to the button's text size
Sub-component text that needs to scale relative to its container, not the root
The PX to REM converter and REM to EM converter handle these conversions separately. The formula for REM is identical to EM except the base is always the root font size, never the parent's.
Chris Coyier's widely referenced CSS-Tricks approach uses PX for the root, REM for modules, and EM for elements inside modules. That 3-layer system keeps global scale predictable while allowing component-level proportional scaling.
Every EM value on a page traces back to a single number: the base font size.
Change that number, and every EM-derived value recalculates. Padding, margins, font sizes, media query breakpoints, all of it shifts.
The 62.5% trick is common in production codebases. Setting html { font-size: 62.5%; } makes 1rem equal 10px, which simplifies mental math considerably. The tradeoff: it forces developers to reset body font-size to 1.6rem just to restore the 16px default, and it overrides whatever the user has set in their browser preferences (LogRocket, 2024).
|
Framework / Context |
Default Root Font Size |
Notes |
|---|---|---|
|
Bootstrap 5 |
16px |
Set on |
|
Tailwind CSS |
16px |
Configurable via |
|
Material UI (React) |
14px |
Affects all rem-based spacing tokens |
|
Plain browser default |
16px |
Overridable by user in browser settings |
Material UI sets its base font size to 14px, not 16px.
A converter output of 1.5em looks correct at a 16px assumption, but inside an MUI component it computes to 1.5 × 14 = 21px, not 24px. The spacing is off by 3px, which sounds minor but breaks pixel-perfect alignment in dense UI layouts.
Always check the framework's default before treating 16 as the base.
Avoid: html { font-size: 16px; } - this locks out users who set a larger default in their browser.
Better approach: Don't set html { font-size } at all, or use a percentage value like html { font-size: 100%; }.
The percentage method preserves the user's browser setting as the actual base. LogRocket (2024) identifies explicitly setting root font-size in px as a common accessibility mistake, because it overrides the browser setting entirely.
WCAG 2.1 Success Criterion 1.4.4 (Resize Text) requires that text scales to 200% without loss of content or functionality.
PX-based font sizes fail this requirement when users change their browser's default font size (not page zoom). EM and REM values pass it because they inherit and scale from the browser setting.
Approximately 2.2 billion people worldwide have vision impairments (WHO, 2026), and many rely on browser font size adjustments rather than screen magnifiers or assistive technology. A site built entirely in PX for typography is invisible to those adjustments.
The W3C's own technique for meeting WCAG 1.4.4 (Technique C28) specifically names EM units as the recommended method for specifying text container sizes.
Using EM for font-size, line-height, and container padding ensures that when a user increases their browser font size from 16px to 20px, all proportional relationships hold. A heading at 2em stays twice the size of body text regardless of what that base is.
94.8% of homepages still failed WCAG conformance checks in 2025, down from 95.9% in 2024 (WebAIM Million, 2025). Unit choice for font sizes is one of the most fixable contributing factors.
EM-based component architecture is most useful when a component needs to render at multiple sizes without separate style overrides.
Etsy switched from PX to REM units in 2021 and reported improved mobile accessibility and conversion rates (FloatUI, 2023). The same logic applies to EM at the component level: when a button or card scales its font-size, all internal EM values scale with it proportionally.
Practical structure:
Set component root font size in REM (global scale)
Set internal text, padding, and margin in EM (local proportional scale)
Result: the component scales globally AND maintains internal proportions
This approach is documented in web design best practices and aligns with how design tokens work in component-driven systems like Storybook and Figma.
5 mistakes show up consistently when developers move from PX to EM. Each one produces values that look right in the stylesheet but compute incorrectly in the browser.
Mistake 1: Using 16 as base when the parent isn't 16px
The fix is to open Chrome DevTools, select the parent element, and read the font-size row in the Computed tab. That's the real base. Assuming 16 without checking is the single most common conversion error.
Mistake 2: Forgetting EM compounding in nested components
A card set to font-size: 1.25em (20px at 16px base) makes its own children compute EM values against 20px, not 16px. Any conversion done at 16px for those children will be wrong. Always convert against the immediate parent's computed size.
Mistake 3: Converting borders and shadows to EM
border-width, box-shadow blur and offset, and fixed-grid icon sizes should stay in PX. These values are not meant to scale with text. Converting them to EM produces borders that thicken when a user enlarges their font size, which looks broken.
Mistake 4: Skipping the Computed tab verification
According to Painless CSS, a widely referenced guide on CSS unit errors, the core mistake isn't using PX - it's applying relative units without verifying the computed output. A CSS value of 1.3125em is only correct if the base assumption matches reality. Open DevTools, check the element, confirm.
Mistake 5: Converting everything at once without a strategy
Switching an entire legacy stylesheet from PX to EM without a plan produces cascading compounding issues. The practical approach: start with typography (font-size, line-height), then move to component-internal spacing, and leave layout-level dimensions and decorative properties in PX.
If you're working across multiple unit systems, the EM to PX converter and EM to REM converter are useful for verifying values in both directions. The PX to PT converter covers print-focused unit translation separately, since PT is a different absolute unit used primarily in print stylesheets and design software export.
Divide the pixel value by the parent element's font size in pixels.
At the browser default of 16px, the formula is: EM = PX ÷ 16. So 24px becomes 1.5em. If the parent font size differs, use that number as the divisor instead.
16px equals 1em when the base font size is 16px.
That's the browser default for most CSS environments. Change the parent's font size and the result shifts. Always verify the computed parent size in DevTools before applying the converted value.
EM values scale with the user's browser font size setting. PX does not.
This matters for accessibility. Users who increase their default font size for readability get proportional scaling with EM-based typography. PX locks text at a fixed size regardless of those preferences.
EM is relative to the nearest parent element's font size. REM is always relative to the root html element.
REM eliminates compounding across nested elements. EM accumulates through nesting. Use REM for global layout and use EM for component-internal spacing that should scale proportionally.
They multiply. Each nested element resolves its EM value against the computed font size of its direct parent, not the root.
Two elements both set to 1.5em, nested inside each other, produce a computed size of 2.25× the base. This is called EM compounding and is the most common source of unexpected sizing bugs.
Google's own Lighthouse accessibility audits flag PX-based font sizes as a potential accessibility issue.
The W3C technique C28 for meeting WCAG 1.4.4 specifically recommends EM units for text containers. Neither enforces a strict rule, but relative units like EM align with accessibility best practices.
Use the computed font size of the parent element for the property you're converting.
That's almost always different from the root. Check the Computed tab in Chrome DevTools or Firefox Developer Tools on the specific parent element. Defaulting to 16 without checking is the most common conversion mistake.
Yes. EM works for any CSS length property, including padding, margin, line-height, and letter-spacing.
When used for spacing, EM resolves against the element's own font size, not the parent's. A button with 0.75em padding scales its spacing proportionally whenever its font size changes.
Only when the parent element's computed font size is 16px.
Frameworks like Material UI default to 14px, which makes 1em equal to 14px inside their components. Always confirm the actual base before treating 1em = 16px as a universal truth.
Apply the EM value in CSS, then open DevTools and check the Computed tab for the element.
The computed font-size row shows the actual rendered pixel value. If it matches your original PX target, the conversion is correct. If not, the base font size assumption was wrong.
Join 28,000+ designers who get curated inspiration, tutorials, and hand-picked free resources every week.
No spam, ever. Unsubscribe with one click.