Pixels Are Dead: Why You Should Stop Using Pixels In CSS

Julien Etienne
7 min readApr 27, 2017


Do you want to design websites like it’s 1999 again? Pixels are the way to go. Go retro, sustain the norms because what you know works already and as long as it works stand on your lawn and shake your fist vigorously…

Pixels Were DOA From Day 1

This article is not about the little red green and blue pixels you see on your screen, don’t worry they’re fine. This is about the use of pixels within HTML & CSS. There is no need for theory, in CSS pixels don’t #f-ing scale, roll credits!

There Must Be A Good Reason Why…

The web is based on 21+ year old standards not designed for today’s world

Exodus 12:8

That same night they are to eat the meat roasted over the fire

The Bible hints that we should eat meat of an animal on the day of slaughter. But we now have refrigerators, freezers and canned food as solutions for new and old problems.

CSS1 says:

Displays are roughly all the same size so use static fonts

Our demands have changed since 1996. We now have a much wider variety of devices, resolutions and display ratios to consider. Despite introducing new features, unlike the food industry the underlying technology hasn’t changed due to:

Backwards Compatibility

And rightfully so because now we all get to endure the misery of the internet.

The Misunderstandings Of Font-Size

In the past I have discussed the topic of font-size misconceptions with several developer and designer colleagues.

The reaction they usually give is as if I am telling them Santa Claus isn’t real for the very first time…

Font-size does not specifically correlate to pixel size on screen

  • One font-family at 16px could have an “A” char 24px high, another font-family at 16px could have an “A” char 26 pixels high.
  • Not taking into account how browsers and operating systems handle kerning, smoothing, and most importantly device pixel ratios in different ways.
  • User-agents each have a different set of defaults on top of that.

So please shut down any talk about “pixel perfect” on the web, it is not possible unless you aim to design a static page for a single browser on a single screen size for a single type of device.


I am not the first nor will be the last to spew this so do check out the other sinners before you cast the first stone. Take a deep breath…

  • FLOATING POINT PRECISION: All font units in CSS (including px) are capable of handling floats in modern browsers. Commonly if 1px is “assumed” the equivalent size of a screen pixel (which is incorrect) it may seem pointless using decimals when designing for a device with a pixel ratio of 1. If viewing those metrics on a device with a DPR of 2/ 3 or 4 an apparent amount of precision is lost due to the avoidance of decimals. REM and EM “encourage” more precision via decimal usage.
  • IT’S AN ILLUSION: Pixels in CSS are NOT real screen sized pixels. They’re actually optical reference units. This confusion sometimes pushes “professional” and experienced web developers to do silly things like create pixels-to-em conversion mixins for CSS pre-processors. This could be why some spend so much time bickering with UX designers over tiny margin/ padding differences. The device pixel ratio depicts the size of the optical reference unit and that depends only on the device or the desktop zoom level set by the user.
  • PX RESULTS IN MORE MAINTENANCE: Not saying anything new here but it’s generally far easier to maintain percentages vs pixel sized containers.
  • RELATIVE SET DIMENSIONS SCALE WITH FONT-SIZE: Always use REM or EM units in places where you usually need to set a fixed width or height. Containers with EM dimensions are relative to it’s font-size. With EM units if you update the font size of a text container, the width or height (set in EMs) will scale proportionately, which means that you only modify 1 value rather than 3 when using pixels. With REM this is true if you change the root font-size of the document.

(Yes EM is more advanced than REM despite being older, also EM works better for media-query breakpoints than REM across browsers for some reason).

There are few circumstances where pixels are necessary and of those circumstances few are to construct an actual layout.


The saddest use of images ever.
See what I did there?

A font-size using EM is relative to its parent container’s font-size. But sometimes compounding is undesirable and harder to maintain. REM units are relative to the document. If in doubt use REM (IE9+) for simplicity.

Using REM Units

If you are coming from the ancient world of pixels you may find it difficult to all of a sudden start using REM units. Here are some tips.

  1. Of course 1rem is 16px in CSS: but 16px in CSS is not a real metric in screen pixels especially with font-size. Therefore REM usage requires the same trial and error guessing game you’ve been doing all along with pixels.
  2. ±0.5 then ±0.25: If you are guesstimating any kind of length, as soon as you get reasonably within proximity, increment or decrement by 0.5, then again by 2.5 before making more specific guesses. This usually saves time.
  3. Use a calculator: The address bar is a calculator in chrome, duh!

The Future Is Cartesian-Like

Example using MIMETIC.js using rem units and percentages.

CSS via HTML already uses a Cartesian Coordinate System, that’s not what I’m disputing here. The problem is that overall it is missing the key ingredient “proportion”. All elements can be in proportion in relation to the viewport using %, vw or vh with the exception of the font-size property. Not even REM units can help. vw and vh units are disregarded as they break zoom accessibility in desktop browsers when used with font-size.

CSS & HTML together make-up an impure 2D framework

This is not the case with SVG. But SVG as of yet does not feature text wrapping or a formatting model.

We are stuck in 1996. To move web design into the 21st century we at least need a proportionate 2D system for font-size.

We need to preserve everything in the x-axis (window width) proportionately. This also make elements of the y-axis scale proportionately but scaling of the y-axis will not affect the scaling of the x-axis.

There have been a few JavaScript attempts to make fonts scale proportionately in the browser, some use pixels and some use em/ rem units. The ones that use pixels are flawed.

So Why Are Pixels Dead?

  • They are static (But technically so are most of the others)
  • They do not respect the root-font size after changes (They are not truly relative to the root font-size like REM and EM units)
  • Properties such as margins, padding and line-height do not scale naturally when re-set in-line.
  • They are assumed as integers which usually results in less accurate implementations on a variety of different pixel ratios.
  • Apparently, Bootstrap 4 is dropping pixels for REM.
  • Pixels create the illusion of being equal to on-screen pixels which leads to misconceptions and in the long run becomes confusing to new developers.
  • Pixels are unlikely to become a viable solution for scaling fonts in the future since design is comprehensively about proportions.

That’s my take on why there is no serious future for pixels in web design!

Thanks for tolerating ;-)