Pixel Density & Resolution-Independent Design

Key takeaways

Every CSS pixel maps to multiple physical pixels on high-density screens; match or exceed the target DPR with your assets or accept visible blur.
SVG is the first-line solution for all non-photographic assets — it is infinitely scalable, often smaller than equivalent 2x PNGs, and requires no multi-density export pipeline.
Use srcset with sizes for responsive raster images so the browser downloads only the density-appropriate source; pair with picture for art direction and modern format negotiation (AVIF first, WebP fallback).
Design at 1x in Figma and export at multiple densities — designing at 2x canvas is an outdated habit that creates rounding errors and misaligns with CSS logical pixel values.
Always set explicit width and height on img elements to prevent layout shift, and serve AVIF/WebP formats to keep multi-density assets fast even at 2x and 3x.

The full lesson

Modern screens cover a huge range of pixel densities. A $200 Android phone can have a 2x display. An Apple Studio Display sits at 2x. The latest iPhones go up to 3x. If your design pipeline still treats one device pixel as one CSS pixel, users on high-density screens will see blurry icons, muddy photos, and soft-looking text. Getting this right is not cosmetic nitpicking — blur erodes trust and perceived quality faster than almost any other rendering problem.

The Core Concept: Device Pixels vs. CSS Pixels

You write web layouts in CSS pixels (also called logical pixels, or density-independent pixels on Android). The browser then maps those CSS pixels to physical device pixels at a ratio stored in window.devicePixelRatio, usually shortened to DPR.

DPR	Marketing name	Common devices (2026)
1x	Standard	Budget Android, older monitors
1.5x	—	Some mid-range Android, entry laptops
2x	Retina / HiDPI	MacBooks, iPad, modern mid-range Android
3x	Super Retina	iPhone 15 Pro and later, flagship Android
4x	—	Rare; some high-end Android phones

A CSS rule of width: 100px always produces an element that is 100 CSS pixels wide. On a 3x display, the browser renders that element using 300 physical pixels. A raster image that is only 100 pixels wide gets scaled up 3x, which makes it look blurry. Resolution-independent design means making sure your visual assets look intentional at every DPR.

Vectors First: SVG and Icon Fonts

The most reliable resolution strategy is to avoid raster images entirely for your UI chrome — icons, logos, dividers, decorative shapes. SVG scales infinitely. File sizes are often smaller than equivalent PNGs at 2x. Modern browsers render SVG with sub-pixel precision.

When to use SVG:

All icons and UI glyphs
Logos and wordmarks
Illustrations built from geometric shapes
Charts and data visualizations (D3, Recharts, and similar tools output SVG natively)
Decorative backgrounds and patterns

When SVG is the wrong tool:

Photographic content (photographs are inherently raster; encode them as AVIF/WebP, not SVG)
Complex illustrations with photorealistic gradients or texture
Content that needs robust color management at print resolution

For inline SVG in HTML, use the viewBox attribute and leave out fixed width/height attributes so CSS can scale the element freely. For SVG used as the src on an img element, add explicit intrinsic dimensions to prevent layout shift, but let CSS control the rendered size.

Responsive Images: srcset, sizes, and the picture Element

For photos and other raster content, the browser’s native responsive image system gives you precise control over which asset gets downloaded at each density and viewport size.

The srcset Width Descriptor

<img
  src="hero-800w.jpg"
  srcset="hero-800w.jpg 800w, hero-1600w.jpg 1600w, hero-2400w.jpg 2400w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Product detail view"
  width="800"
  height="533"
/>

The w descriptor tells the browser the intrinsic pixel width of each source. sizes tells it how wide the image will actually render on screen. The browser then picks the best source by dividing the rendered width by the DPR. On a 3x phone at 390px viewport width, a full-width image needs a source that is at least 1170 physical pixels wide.

Art Direction with the picture Element

Sometimes you need a fundamentally different crop or composition at different viewport sizes — not just a smaller version of the same image. Use picture with source children for that:

<picture>
  <source
    media="(max-width: 600px)"
    srcset="hero-portrait-600w.avif 600w, hero-portrait-1200w.avif 1200w"
    type="image/avif"
  />
  <source
    media="(max-width: 600px)"
    srcset="hero-portrait-600w.webp 600w, hero-portrait-1200w.webp 1200w"
    type="image/webp"
  />
  <img
    src="hero-landscape-1600w.jpg"
    srcset="hero-landscape-800w.jpg 800w, hero-landscape-1600w.jpg 1600w"
    alt="Product detail view"
    width="1600"
    height="900"
  />
</picture>

This pattern delivers the correct crop for mobile, serves modern AVIF/WebP to supporting browsers, and falls back to JPEG. The fallback img still includes srcset for density switching.

CSS Techniques for Density-Aware Styling

The resolution Media Feature

The resolution media feature lets you apply CSS rules based on DPR:

/* 1x default */
.icon {
  background-image: url('icon.png');
  background-size: 24px 24px;
}

/* 2x and above */
@media (resolution >= 2dppx) {
  .icon {
    background-image: url('[email protected]');
  }
}

In practice, you rarely need this for icons anymore — SVG handles it cleanly. The resolution media feature is most useful for CSS background images that must remain raster, like photos used as decorative backgrounds in older design systems.

image-set() for CSS Background Images

This is the modern equivalent of srcset, but for CSS background images:

.card-hero {
  background-image: image-set(
    url('photo.avif') type('image/avif'),
    url('photo.webp') type('image/webp'),
    url('photo.jpg') 1x,
    url('photo@2x.jpg') 2x
  );
}

Browser support for image-set() with type hints reached broad coverage by 2025. Pair it with a plain background-image fallback for safety.

Fluid Typography and rem Units

Text rendering at high density is handled automatically — the browser rasterizes text at the physical pixel level, so fonts look sharp regardless of DPR. What causes sharpness problems is specifying font sizes in px, which breaks browser zoom. Viewport-unit font sizes also break zoom.

The modern pattern is fluid type with clamp() and rem floors:

:root {
  --font-size-body: clamp(1rem, 0.875rem + 0.5vw, 1.25rem);
  --font-size-h1: clamp(1.75rem, 1.25rem + 2.5vw, 3.5rem);
}

This scales smoothly across viewport widths. The rem floor ensures text never drops below a readable minimum and stays zoom-respecting. Variable fonts add another benefit: optical size adjustments (font-variation-settings: 'opsz' 14) optimize rendering for body versus display sizes.

Design Tooling: Designing at 1x

A persistent myth in design teams is that Figma and other tools require you to work at 2x or 3x canvas scale. This is outdated. Modern design tools use CSS-like logical pixels natively — you design at 1x and the export pipeline handles the multiplication.

Correct workflow in Figma (2026):

Design at 1x (a button icon is 24×24 in your frame)
Export the SVG directly — no multiplication needed
For raster assets, use the export panel to generate 1x, 2x, and 3x PNGs at once
Hand off via Dev Mode, which shows CSS values in logical pixels, not physical pixels

Creating a “2x canvas” and then halving all dimensions at handoff introduces rounding errors and makes token values harder to reason about. One Figma frame should map one-to-one with one CSS component at 1x.

Use SVG for all icons, logos, and geometric illustrations — they are inherently resolution-independent.
Serve responsive images with srcset and sizes so the browser picks the optimal source for each DPR and viewport.
Specify width and height attributes on all img elements to prevent layout shift.
Generate 1x, 2x, and 3x raster exports from Figma for any raster asset that cannot be SVG.
Use clamp() with rem units for fluid typography that respects zoom.

Don't

Don’t use low-resolution rasters (1x PNGs) for icons or logos — they look blurry on any 2x or higher display.
Don’t design at 2x canvas scale in Figma and then halve values at handoff — work at 1x and let exports handle density.
Don’t omit sizes from srcset — without it the browser assumes 100vw and downloads images far larger than needed.
Don’t rely solely on CSS resolution media queries to swap raster images when SVG is a viable option.
Don’t use fixed px font sizes — they break browser zoom and provide no fluid scaling benefit.

Asset Optimization for Multi-Density Delivery

Serving the right size is only half the story. File format and compression determine whether those assets are fast.

Format hierarchy for raster images (2026):

AVIF — best compression at equivalent quality; supported in all modern browsers; use as the primary source in picture
WebP — broader legacy support than AVIF; an excellent fallback
JPEG (progressive) — universal fallback for photographic content
PNG — only for content requiring lossless quality or transparency that cannot be served as SVG

A 2x JPEG exported naively from Photoshop is typically 4–8x larger than an equivalent AVIF at the same perceptual quality. For a hero image that must be sharp at 2x, the AVIF version is often smaller than the 1x JPEG baseline.

Tooling recommendations:

Squoosh (Google) — in-browser compression with visual comparison; ideal for manually optimizing critical images
Sharp (Node.js) — production image processing pipeline; integrates with Astro’s image service, Next.js Image, and most SSG build tools
Astro Image component — the Image and Picture components from @astrojs/image generate srcset, sizes, and format variants automatically from a single source file

Platform Considerations: iOS, Android, and Web

The DPR system works the same way across platforms, but the baseline densities differ:

Platform	Minimum expected DPR	Notes
Web (desktop)	1x–2x	Budget monitors at 1x; most MacBooks/Windows HiDPI at 2x
iOS (2026)	2x minimum	All shipping iPhones and iPads are at least 2x; Pro models at 3x
Android	1x–3x	Wide range; design to at least 2x, test at 3x
macOS native apps	2x	Retina Macs set the expectation; use @2x assets as the baseline
visionOS	Vector preferred	Spatial computing surfaces scale dynamically; SVG and system SF Symbols are strongly preferred

For native iOS and Android, the density system works on the same principle. iOS uses @1x, @2x, @3x filename suffixes and asset catalogs in Xcode. Android uses drawable resource buckets (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi). In both cases, using SVG eliminates the multi-bucket problem entirely for UI assets. iOS uses PDF vectors in asset catalogs; Android uses VectorDrawable XML.

Testing Across Densities

The most common mistake in resolution testing is only checking the device you own. Here are a few practical approaches:

Chrome DevTools: the device toolbar lets you set a custom DPR independently of viewport size. Use “Responsive” mode, set DPR to 1, 2, and 3 separately, and inspect icons and images at each setting.
Real devices: emulation is not a substitute for physical hardware on final QA. Borrow or use a device lab to verify on at least one 1x, one 2x, and one 3x device.
Percy / Chromatic visual regression: snapshot tests can capture at multiple DPRs and flag regressions automatically.
Lighthouse image audit: the “Properly sized images” and “Uses efficient cache policy” audits flag images that are oversized for the viewport — a reliable signal that srcset is missing or misconfigured.