The short version
Screen resolution describes a display's hardware or logical pixel grid; viewport describes the page area in CSS pixels; device pixel ratio relates device pixels to CSS pixels. Approximate backing pixels equal CSS viewport pixels multiplied by DPR, but browser UI, zoom and operating-system scaling affect reported values.
What matters most
- CSS pixels are layout units, not guaranteed hardware pixels.
- Viewport excludes some browser interface and can change dynamically.
- DPR influences image candidate selection but does not describe display size or sharpness alone.
How to apply it
- Read viewport width and height from the browser context.
- Read window.devicePixelRatio and note browser zoom or OS scaling.
- Multiply CSS dimensions by DPR for an approximate backing-store requirement.
- Use element layout width—not full screen resolution—for responsive images.
- Test screenshots and assets on the actual browser/device workflow.
Reference table
| Measurement | Unit | Describes | Example |
|---|---|---|---|
| Screen resolution | Device/logical pixels | Display grid reported by system | 2560 × 1440 |
| Viewport | CSS pixels | Web page's visible layout area | 1280 × 720 CSS px |
| DPR | Ratio | Device pixels per CSS pixel | 2 |
| Image slot | CSS pixels | Rendered element width | 600 CSS px |
Use exact dimensions and units in production notes; familiar labels can describe more than one standard.
Separate the coordinate systems
Web layout uses CSS pixels so interfaces remain usable across displays with different densities. The operating system and browser map those units to a backing store and physical display. A CSS rectangle 300 pixels wide can therefore use more than 300 device samples on a high-DPR context.
Screen APIs may report logical rather than raw panel pixels depending on platform scaling. Treat values as measurements of the current software context, not as laboratory specifications for the hardware panel.
- Label CSS and device pixels explicitly.
- Do not infer physical inches from DPR.
- Expect platform-dependent screen reporting.
Expect the viewport to change
Desktop viewport follows the browser content area, not the whole monitor. On mobile, address bars, toolbars, keyboards and orientation can change visible dimensions. Layout viewport and visual viewport can also differ during zoom or keyboard display.
Design responsive breakpoints around content behavior rather than specific phone model names. Test narrow and wide ranges, text zoom and dynamic interface states. A page that fits one advertised screen resolution can still overflow in the real viewport.
- Use content-driven breakpoints.
- Test orientation and browser UI changes.
- Avoid device-name assumptions.
Apply viewport and DPR to image delivery
Responsive images should use the element's likely CSS slot width. Multiplying that slot by DPR gives a useful intrinsic-width estimate: a 500-CSS-pixel image at DPR 2 may need around 1000 source pixels. Full screen resolution is irrelevant when the image occupies only part of the layout.
Provide several efficiently compressed candidates and accurate sizes markup. The browser may choose a larger cached candidate or account for zoom and heuristics. Measure actual requests rather than demanding one deterministic file in every condition.
- Start with layout slot width.
- Use DPR as a density multiplier.
- Allow native browser selection.
Handle screenshots and canvas deliberately
A screenshot tool may capture CSS viewport dimensions, backing-store dimensions or the full page, depending on its API. Record both CSS and output raster sizes when pixel-exact evidence matters. Do not assume a phone screenshot equals the page viewport.
For canvas and other raster rendering, scale the backing store for DPR while keeping CSS display dimensions stable, then draw accordingly. Cap extreme sizes to avoid memory problems and verify text and lines remain crisp without changing layout geometry.
Common mistakes to avoid
- Using screen.width as the image's rendered layout width.
- Assuming DPR equals physical pixel density in PPI.
- Ignoring browser zoom and OS display scaling.
- Capturing a screenshot and labeling CSS viewport values as file pixels.
Continue with the right tool
Use a calculator to check the numbers against your own source and destination instead of relying on a generic preset.
Related guides
Frequently asked questions
Is DPR 2 always a Retina display?
It indicates a two-to-one mapping in the current browser context, not a complete physical-density classification.
Why is viewport smaller than screen resolution?
Browser chrome, window size, scrollbars, zoom and CSS pixel mapping reduce or transform the page area.
What image width is needed for a 600px slot at DPR 2?
Roughly 1200 intrinsic pixels is a useful planning candidate, while browser selection can vary.
Can DPR change?
Yes. Zoom, moving a window between displays and operating-system settings can affect the reported value.
Sources and further reading
These references support the technical definitions and platform-specific guidance used above.
- MDN — Window.devicePixelRatioBrowser reference for DPR and zoom behavior.
- MDN — Visual Viewport APIReference for layout and visual viewport differences.