EM vs REM vs PX – Why you shouldn't “just use pixels”

rich-text

The debate has been had many times: what units of measurement should we use in our CSS?

Pixels are familiar. REMs are useful. EMs still have their place. But if you’re choosing between REM vs EM vs PX, the answer isn’t really about which unit developers prefer. It’s about how your interface behaves for the people using it.

We, like many others, were once ready to ditch REMs and return to the beloved pixel. They’re easy to understand, easy to design with, and easy to translate into build. But we lost track of why we adopted REMs in the first place.

The problem doesn’t just revolve around font sizes. It’s also about accessibility, scalability, and remembering that users should be able to browse the web in a way that works for them.

TL;DR:

Pixels are not evil, but they should not be the default for everything.
Use REMs for scalable font sizes, spacing, and layout values.
Use EMs when sizing should respond to the context of a component, especially in media queries.
Use pixels for fixed details like borders, shadows, and small visual refinements.

REM vs EM vs PX: quick comparison

There isn’t one perfect CSS unit for every job. Pixels, REMs and EMs all behave differently, which is exactly why blindly using one of them everywhere can create problems. The trick is knowing where each unit makes sense, and where it might come back to bite you.

Unit	What it is	Best used for	Watch out for
PX	A fixed CSS unit that gives you a precise value.	Borders, shadows, icons, small visual details and anything that needs to stay fixed.	Not ideal as the default for font sizes or major spacing, as it can work against user font-size preferences.
REM	A relative unit based on the root HTML font size.	Font sizes, spacing, layout values and scalable design systems.	It depends on how the root font size is set, so changing that value can affect the whole interface.
EM	A relative unit based on the font size of the current element or parent context.	Component-level sizing, nested UI elements and media queries where values should respond to context.	EMs can compound when nested, which can make sizing harder to predict if you’re not careful.

How to choose between REM, EM, and PX

Use the unit that matches the behaviour you want. If something should scale with the user’s settings, use REM. If it should respond to the size of a component, EM can make sense. If it needs to stay fixed, pixels are still allowed. We won’t tell anyone.

REM vs EM

REM and EM are both relative units, but they are relative to different things.

REM is based on the root HTML font size, so 1rem means the same thing wherever you use it. That makes REMs a safer choice for consistent font sizes, spacing and layout values.

EM is based on the font size of the current element or parent context. That can be useful inside components, but it can also get messy when values are nested. Use REM when you want consistency. Use EM when you want something to scale with its immediate context.

REM vs PX

Pixels are fixed. If you set a heading to 30px, it stays 30px.

REMs are more flexible because they can scale from the root font size. That makes them a better default for typography, spacing and layouts where user preferences should be respected.

Pixels are not evil. But if you use PX for every font size and major spacing value, you’re probably making the web more rigid than it needs to be.

EM vs PX

PX gives you precision. EM gives you flexibility.

A 2px border should probably stay as 2px. But if you want button padding, icons or spacing to scale with the text inside a component, EM can be useful.

Use PX when something should stay fixed. Use EM when something should move with its context.

How to convert REM to PX

REM to PX conversion depends on the root font size.

If the root font size is 16px, which is the common browser default, then:

REM value	PX value
1rem	16px
1.25rem	20px
1.5rem	24px
1.6rem	25.6px
2rem	32px

The formula is:

REM value × root font size = pixel value

So 1.6rem to PX is 1.6 × 16 = 25.6px.

To convert 24px to REM, divide by the root font size:

24 ÷ 16 = 1.5rem

That is why 1rem is usually 16px, but only if the root font size has not been changed.

What about media queries?

So we’ve established that using pixel values can override browser default settings, and that REMs are generally a better option for scalable font sizes and spacing. Does that mean every pixel value should be converted to REM?

Not quite.

Media queries are where things get more awkward. In theory, using relative units like EMs can make sense because breakpoints can respond more naturally to changes in font size. That matters when users have adjusted their browser settings, not just when they resize the viewport.

But there are edge cases. Browser zoom, default font-size changes and overlapping min-width / max-width rules can all create awkward breakpoint behaviour. Lovely.

The practical advice is to keep your breakpoint logic as simple as possible. Avoid writing overlapping min-width and max-width media queries for the same breakpoint when you can. Instead, set a sensible base style, then override in one direction.

For example:

body {

   background: blue;

   @media screen and (min-width: 64em) {

       background: red;

   }

}

This avoids asking the browser to choose between two almost identical breakpoint rules, which is where rounding issues can start to creep in.

There are still trade-offs. EM-based media queries can take a bit more thought, especially if you’re used to working in pixels. It can also mean writing your CSS in a slightly different way, rather than relying on tightly paired min-width and max-width rules.

But if your aim is to build layouts that respect user settings, EMs are still worth considering.

Remember who you’re building websites for.

Browsers change, devices change, and users do not browse the web in the neat little boxes we sometimes design for. So whatever unit you choose, test it properly, especially with browser zoom and adjusted default font sizes.

Further reading:

• Just use pixels
• R.I.P. REM, Viva CSS Reference Pixel!
• Length - Mozilla Developer Network

Build for the people using it

Choosing between REM, EM and PX might feel like a small technical decision, but small decisions add up quickly. Typography, spacing, breakpoints and accessibility all shape how a website feels, works and scales.

That is why good digital work needs both sides of the conversation: design that thinks beyond the static mockup, and development that respects the user, the browser and the real world.

If you’re planning a new site, refreshing an existing one, or trying to make your digital experience work harder, our web development team can help you build it properly. And if you need the design thinking to go with it, our digital design team can help make sure it looks, feels and functions the way it should.

FAQs

What is the difference between REM, EM and PX?

REM, EM and PX are all CSS units, but they do not behave in the same way. PX is fixed, REM is based on the root HTML font size, and EM is based on the font size of the current element or parent context. In short: PX gives you control, REM gives you consistency, and EM gives you context.

Should I use REM or PX for font sizes?

In most cases, use REM for font sizes. REMs are more flexible because they can scale with the root font size, which makes them better for accessibility and consistent design systems. Pixels can still be useful, but they should not be the default for every bit of text. Users exist. Annoyingly, we should probably design for them.

How do you convert REM to PX?

To convert REM to PX, multiply the REM value by the root font size. If the root font size is 16px, then 1rem is 16px, 1.5rem is 24px, and 1.6rem is 25.6px. If the root font size changes, the conversion changes too. That is the whole point.

Should media queries use EM, REM or PX?

EMs are often a good option for media queries because they can respond more naturally to user font-size settings. PX media queries are easier to understand, but they are fixed. REMs can work too, but they have not always behaved as consistently across browsers. As ever, the boring answer is the right one: choose the unit deliberately, keep your breakpoint logic simple, and test properly.