PX to EM Converter
Enter a pixel value and get the EM equivalent instantly. Adjust the base font size to match your project.
| Pixels (PX) | Em Units (EM) |
|---|
What Is a PX to EM Converter?
A px to em converter takes a pixel value and returns its em equivalent, based on whatever font size you tell it to use as the reference point.
The output isn't fixed. Change the base font size and the same 20px input spits out a different em value every time.
What the tool actually needs and gives back:
- An input pixel value, the size you're trying to convert
- A base font size to divide against, defaulting to 16px on most tools
- An output in em, often paired with a rem equivalent for comparison
It doesn't touch image dimensions, and it has nothing to do with device pixel ratio on retina screens. Those are separate problems entirely.
PX vs EM: What Is the Core Difference?
An element set to 16px stays 16px no matter where it sits on the page.
Em is relative. It scales against the font size of whatever element it's attached to, which is why the same "1em" produces different physical sizes in different spots on the same page.
That's the core split between the two: one unit is absolute, the other is relative and depends entirely on its surroundings.
Two units, two behaviors:
- Px does not care about parent font size, inheritance, or nesting depth
- Em always checks the computed font-size of its reference element before calculating anything
- A 1.5em value inside a 20px parent renders differently than the same 1.5em inside a 16px parent
Tracing what the px abbreviation stands for makes the fixed behavior easier to remember. It's tied to physical screen pixels, not to any typographic context.
Em works the opposite way. A closer look at how the em unit is defined in css shows it was built specifically to scale alongside text, not against a fixed screen measurement.
EM vs REM: How Do They Differ?
Rem always points to the root element, meaning the html tag's font size and nothing else.
Em points to whatever is closest: the immediate parent, not the document root.
| Unit | Reference point | Compounding risk | Best fit |
|---|---|---|---|
| Em | Immediate parent element | High in nested markup | Component-level scaling |
| Rem | Root html element | None | Global typography and spacing |
| Px | Fixed, no reference point | None | Borders, icons, fixed UI |
Rem's predictability comes directly from that fixed anchor point. Change the root font size once, and every rem value across the page adjusts in lockstep.
Large design systems run into this regularly. A hardcoded 16px root value blocks user-driven font size adjustments, which is why teams auditing their systems for accessibility tend to move global sizing to rem.
A closer breakdown of how em and rem behave differently in practice comes down to that one reference point difference. Everything else follows from it.
For teams standardizing on one relative unit, understanding how rem compares to px matters more than memorizing conversion tables. The definition explains the behavior.
Why EM Values Compound in Nested Elements
Each nested em multiplies against its parent's computed size, not against the original base value.
A div at 20px containing a p at 1.5em produces 30px text. Nest another element inside that p at 1.5em, and it renders at 45px, not 30px again.
Baseline browser support for both units has been stable for over a decade, so compounding is a design choice, not a compatibility gap:
- Em dates back to the original CSS1 specification in 1996 and has worked in every browser since
- Rem followed later, landing in Chrome 4, Firefox 3.6, Safari 5, and Internet Explorer 9, all around 2010 and 2011
Nobody is fighting old browsers here. The compounding problem is baked into how em was designed to work, not a bug anyone needs to patch.
How Does PX to EM Conversion Work?
The formula is short: em = target pixels รท base font size.
Divide the pixel value you want by whatever font size is doing the dividing, and the result is your em value.
| Target px | Base font size | Result in em |
|---|---|---|
| 20px | 16px | 1.25em |
| 20px | 20px | 1em |
| 24px | 16px | 1.5em |
Same 20px input, two different answers, purely because the base font size changed. That's the entire mechanism in one table.
Rounding matters more than people expect. Carrying the result to two or three decimal places avoids visible drift when several converted values sit next to each other on a page.
Round too aggressively, say to whole numbers, and spacing that should line up perfectly starts looking slightly off, especially in dense UI like data tables or form grids.
What Role Does Base Font Size Play in Conversion?
Base font size is the divisor in every single em calculation. Change it, and every em value built on top of it shifts at once.
Most of the time, that base comes from the font-size property set on the html or body element.
How inheritance actually flows:
- A nested element inherits font size from its direct parent, not from the document root
- Setting font-size on a wrapping div changes the em calculation for everything inside it
- Design systems that adjust their base size retroactively shift every em-based measurement built on that system
- A component moved into a differently-styled parent container can change size on its own, without a single property being edited on the component itself
This is the part that catches people off guard.
A component built with em units doesn't just resize when its own font-size changes. It resizes when any ancestor's font-size changes too.
How Do Browsers Set Default Font Size?
Every major browser ships with the same default root font size unless a stylesheet overrides it.
Key figures worth knowing:
- 16px is the default root font size in Chrome, Firefox, Safari, and Edge, a browser default rather than a value the CSS specification requires
- In WebAIM's 2018 Survey of Users with Low Vision, 44.0% of respondents used browser zoom and 36.7% used browser text sizing
- Internet Explorer's older versions applied text zoom differently than the evergreen browsers in use today
That matters. Most people never touch the default, but more than a third of low-vision users change text size through the browser itself, and a page built in px ignores that setting.
Confirming that behavior across every engine, not just the two or three you personally test in, is what cross-browser compatibility work is for. A page that scales cleanly in Chrome can still break in an older engine.
When Should You Use EM Instead of PX?
Use em when an element needs to scale with its own local context, not with the page as a whole.
Cases where em earns its place:
- Buttons, badges, and form fields that need to grow or shrink together as a unit
- Typography that needs to respect a user's font size preference rather than override it
- Spacing inside a component that stays proportional to that component's own text size
- Icon and text pairings where the icon should track any font size change made to its label
WCAG 2.1's Success Criterion 1.4.4 requires that text resize up to 200% without breaking content or functionality (W3C, Level AA). Fixed pixel text makes that requirement much harder to satisfy cleanly.
This is where accessible typography and unit choice overlap directly.
A font size locked to px ignores a user's browser preferences. One set in em respects them by default.
The same logic extends to layout, not just type. Teams building responsive typography systems often lean on em specifically, since it lets a component's whole type scale shift with one variable instead of touching every declared size by hand.
EM or REM for Responsive Design?
Neither unit wins outright. The choice depends on what you're trying to keep predictable, one component, or the whole page.
| Responsive design layer | Better fit | Why |
|---|---|---|
| Global typography scale | Rem | One root change cascades everywhere at once |
| Reusable UI components | Em | Scales locally wherever the component gets dropped |
| Codebase-wide size audits | Rem | Every value traces back to a single source |
| Embedded third-party widgets | Em, scoped carefully | Avoids inheriting an unexpected host page font size |
Bootstrap's own documentation sets its base font size in rem specifically so the framework respects the browser's default root font size, typically 16px, rather than overriding it. The stated goal is a more inclusive and accessible type scale.
That's a large, widely used framework choosing predictability over local flexibility at the root level, then still leaving room for em inside individual components.
Large teams building out a full responsive design system tend to converge on rem for anything shared globally, and reach for em only inside a component that needs to scale as a self-contained unit.
What Are the Pros and Cons of Using EM Units?
Em isn't universally better or worse than rem or px. It's a trade-off, and the trade-off shows up clearly once you list it out.
Where em helps:
- Keeps a component's internal proportions locked together as one unit
- Lets a single font-size change ripple through everything nested inside it
- Works well for badges, tags, and buttons that get reused across a codebase
Where em causes friction:
- Deep nesting compounds values fast, and the math stops being obvious
- Debugging a rendered size in Chrome DevTools means walking up the parent chain by hand
- Two components with identical em values can render at completely different physical sizes depending on where they sit
A common version of that friction: a hardcoded px font-size sitting on the body element, overriding every em-based component inside it and taking away the user's control over their own base font size.
The fix isn't about em versus rem in the abstract. It's about one fixed value quietly breaking the assumptions every relative unit downstream was built on.
How to Convert PX to EM Step by Step
The math from earlier sections turns into a repeatable process once you follow it in order.
- Identify the base font size of the target element's parent context, not just the html default
- Divide the pixel value you want by that base font size
- Apply the resulting decimal value to the relevant CSS property: font-size, margin, or padding
- Open Chrome DevTools or Firefox's inspector and check the computed pixel value against what you expected
- Adjust and repeat if the parent's font size wasn't what you assumed it was
That last step catches more mistakes than the formula itself ever does. Most conversion errors trace back to a wrong assumption about which element's font size was actually doing the dividing.
A quick sanity check: if a converted value looks off by exactly a clean multiple, double or half, the base font size assumption is almost always the culprit, not the arithmetic.
Which CSS Properties Work Best With EM Units?
Font-size is where em was designed to live. Everything else is a secondary use case built on top of that original purpose.
Where em pulls its weight:
- Font-size, the property em was originally built for
- Margin and padding on components that should scale with their own text size
- Icon and text pairings where the icon needs to track any font size change made to its label
Line-height is the exception worth flagging. A unitless line-height value, just a number with no unit at all, usually beats an em-based one, since unitless values don't compound the way em does when inherited by nested text.
Using EM in Media Query Breakpoints
Breakpoints written in em used to carry real risk in one specific browser.
Older versions of Safari handled em-based media queries inconsistently when a page was zoomed, so breakpoints could trigger at a different width than in Chrome or Firefox.
Current Safari releases behave the same way as the other engines, and em-based breakpoints now respond to zoom consistently everywhere.
That history is why some older advice still recommends px for breakpoints specifically. Most of that advice is outdated now, since the inconsistency it was written around no longer shows up in current browsers.
Modern media queries written in em still respond correctly to a user's default font size setting, not just to viewport width, which is the main reason the unit remains popular for breakpoints today.
When Does PX to EM Conversion Not Apply?
Not every measurement on a page benefits from being converted. Some contexts call for px specifically, and converting them to em creates problems instead of solving them.
| Context | Why px stays fixed |
|---|---|
| Icons and 1px dividers | Needs to stay fixed regardless of surrounding text size |
| Print stylesheets | Physical units anchor better than font-relative ones on paper |
| SVG and canvas elements | Font-relative units don't apply the same way here |
| HTML email templates | Several major email clients don't reliably support relative units |
The W3C's own css specification backs up the print case directly. For print media at typical viewing distances, the recommended anchor unit is a physical one, inches or centimeters, not the pixel-based unit that em ultimately depends on.
Email rendering is its own separate problem. Documentation from email-focused build tools like jsx-email notes that older Outlook versions and AOL don't reliably support rem values, which is why many email-safe stylesheets convert everything back to px before shipping.
SVG text and shapes follow their own sizing model, one that doesn't inherit font-relative units the way regular HTML elements do. Converting an SVG's internal measurements to em rarely produces the result someone expects.
Design systems that standardize hard on px for pixel-perfect fidelity across every breakpoint aren't wrong to do so. They're making a deliberate trade against the flexibility em and rem normally provide, and that trade can be the right one for a tightly controlled visual product.
FAQ on PX to EM Converter
How Do You Convert PX to EM Using Sass, Less, or PostCSS?
All three support a simple division function. Sass and Less let you write a custom em($px, $base) function that divides pixels by the base font size.
PostCSS plugins automate that math across a whole stylesheet: postcss-px-to-em converts to em, and the more popular postcss-pxtorem does the same for rem.
How Do You Convert PX to EM in Tailwind or Bootstrap?
Tailwind's spacing and typography scale is rem-based by default, so conversion happens automatically through its config file.
Bootstrap sets its base font size in rem too, letting both frameworks respect a user's default root font size instead of hardcoding pixels.
Does Browser Zoom Affect EM-Based Sizing?
Yes. Browser zoom scales the whole page, pixels included, so an em value tied to a zoomed parent grows right along with it.
Font-size-only adjustment settings behave differently, affecting relative units like em and rem, not raw pixel values.
How Accurate Is a PX to EM Converter Tool?
It's exact, not approximate. The formula is fixed division, so the output is mathematically precise every time.
Accuracy problems trace back to a wrong base font size assumption, not the tool's math, which is why checking DevTools still matters.
Can You Convert EM Back to PX?
Yes, by reversing the formula: multiply the em value by the same base font size used in the original conversion.
The result only matches the original pixel value if that base font size hasn't changed anywhere in between.
Do Design Tools Like Figma Export EM Values?
Not directly. Figma, Sketch, and Adobe XD all design in pixels, since design files carry no CSS cascade or inherited font size. Figma's Dev Mode can display values in rem, but not in em.
Developers convert those pixel values to em during implementation, based on the font size of the element's actual parent.
What Should You Prioritize After Running a PX to EM Converter?
A PX to EM Converter finishes the math instantly, but the accessibility payoff only lands once you verify base font size, check computed values, and standardize the unit across the whole codebase, not one converted value in isolation.
Three priorities decide whether that conversion actually holds up in production.
- Lock the base font size project-wide before converting anything
- Convert typography first, spacing second, fixed UI elements last
- Test computed values at 200% browser zoom before shipping
Skipping that order produces a page where badges scale correctly but headings don't, which is harder to debug than starting from px in the first place.
Standardizing on one relative unit trades component-level portability for page-wide predictability, a deliberate trade-off, not a free upgrade.
Once base font size and rounding are settled, the next practical comparison is px vs rem, since most teams end up mixing both rather than converting everything to one unit.