CSS Pixels vs Physical Pixels: The Complete Developer Guide

The Problem With "Pixels"

Here is a scenario that confuses almost every developer when they first encounter it. A designer hands you a Figma mockup that is 375 px wide. You open it on your iPhone 16 Pro, which has a physical screen resolution of 1320 × 2868 pixels. The design looks perfect — not squished, not stretched, just right. How is that possible when the numbers are so wildly different?

The answer is that the word "pixel" means two completely different things depending on context. There are physical pixels — the actual hardware light-emitting dots manufactured into your screen — and there are CSS pixels, the abstract unit the web platform uses for layout and measurement. Confusing the two is the root cause of blurry images, text that looks too small on some devices, and responsive layouts that break in unexpected ways on high-density screens.

This distinction has existed since Apple introduced the Retina display with the iPhone 4 in 2010, but it still trips up experienced developers. Let's go through it carefully, because once it clicks, a lot of other things in web development start to make more sense.

Physical Pixels Explained

A physical pixel — sometimes called a hardware pixel or device pixel — is a single light-emitting dot on a display panel. It is the smallest unit the screen hardware can control independently. When you look at a screen under a magnifying glass, you are seeing physical pixels.

The total count of physical pixels is what manufacturers advertise as "resolution." A modern iPhone 16 Pro has a screen that is 1320 × 2868 physical pixels. A 27-inch 4K monitor has 3840 × 2160. These numbers represent the raw resolving power of the hardware — the more physical pixels per inch, the sharper the image.

Pixel density is measured in pixels per inch (PPI). A typical 24-inch 1080p monitor sits around 92 PPI, which is comfortable for viewing at arm's length (roughly 60 cm). A smartphone screen is held much closer — typically 25–35 cm — so manufacturers push density to 400–500 PPI to keep individual dots invisible to the naked eye. Apple's marketing term "Retina display" simply means the PPI is high enough that individual pixels are not distinguishable at the device's typical viewing distance.

Notice that the 4K monitor has a lower PPI than the MacBook Pro despite having more total pixels. That is because the monitor is much larger. PPI is what determines perceived sharpness, not raw pixel count.

CSS Pixels: The Logical Layer

A CSS pixel is not a hardware dot. It is an abstract unit defined by the W3C CSS specification as approximately 1/96th of an inch at a "reference viewing distance." On a standard 96 PPI monitor, one CSS pixel maps to exactly one physical pixel. On a high-density display, one CSS pixel maps to multiple physical pixels.

This abstraction exists for a very practical reason: it means web content does not need to know anything about the underlying hardware. When you write width: 375px in CSS, you are working in CSS pixels. The browser handles the translation to physical pixels automatically. Your layout will look roughly the same physical size on a phone and a laptop, even though the hardware pixel counts are completely different.

Think of CSS pixels as "intent units." You are telling the browser "I want this element to be 375 units wide," and the browser figures out how many physical dots that corresponds to on the specific screen it is rendering on.

JavaScript gives you access to the CSS pixel dimensions of the viewport throughwindow.innerWidth and window.innerHeight. These are always in CSS pixels. The screen.width and screen.height properties, on the other hand, return physical pixel dimensions — a distinction that catches many developers off guard.

// CSS pixel viewport size (what your layout sees)
console.log(window.innerWidth);   // e.g. 390 on iPhone 16 Pro
console.log(window.innerHeight);  // e.g. 844

// Physical pixel screen size (the hardware resolution)
console.log(screen.width);        // e.g. 1170 on iPhone 16 Pro
console.log(screen.height);       // e.g. 2532

Device Pixel Ratio (DPR): The Bridge

The ratio between physical pixels and CSS pixels is called the Device Pixel Ratio (DPR), exposed in JavaScript as window.devicePixelRatio. A DPR of 2 means that for every one CSS pixel, the screen uses a 2×2 block of four physical pixels. A DPR of 3 means a 3×3 block of nine physical pixels.

You can read the current DPR in JavaScript at any time:

console.log(window.devicePixelRatio);
// 1    → standard monitor
// 1.5  → some Windows laptops with 150% scaling
// 2    → MacBook, most mid-range phones
// 2.625→ Google Pixel 8
// 3    → iPhone 16 Pro, Samsung Galaxy S25 Ultra

DPR is not always a whole number. Many Android devices use fractional ratios — 1.5, 2.625, 2.75 — because the manufacturer chose a physical resolution that does not divide evenly into a standard CSS viewport size. This can cause subtle sub-pixel rendering artefacts if you are not careful with your image sizes.

You can verify these numbers for any device in the Viewport Reference on this site, which lists CSS viewport sizes and physical resolutions for over 185 devices.

Images & Retina Sharpness

The most visible consequence of DPR is image sharpness. If you place a 200 × 200 CSS pixel image on a DPR-2 screen, the browser stretches it across a 400 × 400 physical pixel area. Unless the source image is at least 400 × 400 physical pixels, it will appear blurry — you are asking the browser to invent pixels that do not exist in the source file.

This is why logos and hero images often look crisp on your development laptop but blurry on your phone. Your laptop might be DPR 1 or 2, but you are testing on a DPR-3 device.

The srcset Solution

The correct fix is to serve higher-resolution images on high-DPR screens using the srcset attribute. The browser will automatically choose the most appropriate source based on the current DPR:

<img
  src="logo-1x.png"
  srcset="logo-1x.png 1x,
          logo-2x.png 2x,
          logo-3x.png 3x"
  alt="DeviceSpecsHub logo"
  width="200"
  height="200"
/>

For responsive images where the display size varies with the viewport, use the w descriptor with a sizes attribute instead:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w,
          hero-800.jpg 800w,
          hero-1600.jpg 1600w"
  sizes="(max-width: 640px) 100vw,
         (max-width: 1024px) 80vw,
         1200px"
  alt="Hero image"
/>

Modern Image Formats

Modern image formats like WebP and AVIF compress high-resolution images far more efficiently than PNG or JPEG. A 3× PNG might be 400 KB; the same image as AVIF might be 60 KB with identical visual quality. Use the <picture> element to serve AVIF with a JPEG fallback:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero image" width="1200" height="630" />
</picture>

For icons and logos, use SVG wherever possible. SVG is resolution-independent — it will look perfectly sharp at DPR 1, 2, 3, or any fractional value, with no extra file size.

Viewport & Media Queries

CSS media queries operate in CSS pixels, not physical pixels. This is one of the most important things to understand about responsive design. An iPhone 16 Pro has a physical width of 1320 px but a CSS viewport width of just 440 px (at DPR 3). This is why your breakpoints work correctly on phones — @media (max-width: 768px) fires at 768 CSS pixels, which covers the vast majority of smartphones regardless of their physical resolution.

If media queries used physical pixels, you would need to write different breakpoints for every device density tier, which would be completely unmanageable. The CSS pixel abstraction is what makes responsive design practical.

There is one exception: the resolution media feature (and its older vendor-prefixed equivalents) does let you target specific DPR values. This is useful for serving high-resolution background images in CSS:

/* Standard resolution background */
.hero {
  background-image: url('hero-1x.jpg');
}

/* High-DPR screens: serve 2× background */
@media (-webkit-min-device-pixel-ratio: 2),
       (min-resolution: 2dppx) {
  .hero {
    background-image: url('hero-2x.jpg');
  }
}

/* Very high-DPR screens: serve 3× background */
@media (-webkit-min-device-pixel-ratio: 3),
       (min-resolution: 3dppx) {
  .hero {
    background-image: url('hero-3x.jpg');
  }
}

You can check both the CSS viewport size and the physical resolution for any device in the Viewport Reference on this site. The "CSS Viewport" column is what your media queries see; the "Resolution" column is the physical pixel count.

The 1px Border Problem

On a DPR-2 screen, border: 1px solid is rendered as 2 physical pixels wide. On a DPR-3 screen, it is 3 physical pixels wide. This can look heavier than intended, especially for dividers and table lines where you want the thinnest possible line.

Designers working in tools like Figma often specify 0.5 px borders to achieve a single physical pixel line on Retina screens. In CSS you can approximate this with:

/* Single physical pixel border on high-DPR screens */
.hairline {
  border: 1px solid #e2e8f0;
}

@media (-webkit-min-device-pixel-ratio: 2),
       (min-resolution: 2dppx) {
  .hairline {
    border-width: 0.5px;
  }
}

/* Alternative: use a pseudo-element scaled to 0.5px */
.hairline-alt {
  position: relative;
}
.hairline-alt::after {
  content: '';
  position: absolute;
  bottom: 0;
  left: 0;
  right: 0;
  height: 1px;
  background: #e2e8f0;
  transform: scaleY(0.5);
  transform-origin: bottom;
}

The 0.5px approach works in Safari and most modern browsers. The pseudo-element approach with scaleY(0.5) is more universally supported and gives you a true 0.5 CSS pixel (1 physical pixel on DPR-2) line.

Performance Considerations

High DPR screens do not just affect visual quality — they affect performance too. A DPR-3 screen has nine times as many physical pixels as a DPR-1 screen of the same CSS size. The browser has to composite and render all of those pixels, which means animations and canvas operations are more expensive on high-density displays.

For canvas-based applications, you should always scale the canvas element to match the DPR:

const canvas = document.getElementById('myCanvas');
const ctx = canvas.getContext('2d');
const dpr = window.devicePixelRatio || 1;

// Set the canvas size in physical pixels
canvas.width = canvas.offsetWidth * dpr;
canvas.height = canvas.offsetHeight * dpr;

// Scale the context so drawing commands use CSS pixels
ctx.scale(dpr, dpr);

// Now draw normally — coordinates are in CSS pixels
ctx.fillRect(10, 10, 100, 50);

Without this scaling, canvas drawings will appear blurry on Retina screens. With it, they will be crisp — but at the cost of rendering four to nine times as many pixels. For complex canvas scenes, consider capping the effective DPR at 2 even on DPR-3 devices:

const dpr = Math.min(window.devicePixelRatio || 1, 2);

This gives you Retina-quality output without the full DPR-3 performance cost. Most users cannot tell the difference between DPR-2 and DPR-3 canvas rendering at typical viewing distances.

Debugging DPR Issues

When something looks blurry or wrong on a specific device, these are the first things to check:

Check the DPR in the browser console

// Open DevTools console on the device or in emulation mode
console.log('DPR:', window.devicePixelRatio);
console.log('CSS viewport:', window.innerWidth, '×', window.innerHeight);
console.log('Physical screen:', screen.width, '×', screen.height);

Use Chrome DevTools device emulation

Chrome DevTools lets you emulate specific devices including their DPR. Open DevTools, click the device toolbar icon, and select a device from the dropdown. The "Device pixel ratio" field in the custom device settings lets you test any DPR value. This is the fastest way to catch blurry image issues before they reach real users.

Check image natural size vs display size

// Check if an image is being upscaled (potential blurriness)
const img = document.querySelector('img.hero');
const dpr = window.devicePixelRatio;

console.log('Display size (CSS px):', img.offsetWidth, '×', img.offsetHeight);
console.log('Required physical px:', img.offsetWidth * dpr, '×', img.offsetHeight * dpr);
console.log('Actual image size:', img.naturalWidth, '×', img.naturalHeight);

if (img.naturalWidth < img.offsetWidth * dpr) {
  console.warn('Image is being upscaled — will appear blurry on this screen');
}

You can also check your own device's DPR and CSS viewport size right now using the What is My Resolution tool on this site.

Practical Takeaways

Understanding the CSS pixel / physical pixel distinction shapes several everyday decisions. Here is a quick reference for the most common situations you will encounter:

The core mental model is simple: write everything in CSS pixels, and only think about physical pixels when you are dealing with raster images or canvas. The browser's job is to bridge the gap — let it do that job, and only intervene when the default behaviour is not good enough.

If you want to see these concepts in action for your own device, the What is My Resolution tool shows you both your CSS pixel resolution and your physical pixel resolution side by side, along with your current DPR. The Viewport Reference lists the same data for over 185 devices — useful for understanding how your layouts will behave across the full range of screens your users have.