The Viewport and Device Pixels

• The CSS pixel is a reference unit, not a hardware one. It is defined so that content of the same CSS size appears at a similar physical size across devices at typical viewing distances — closer for a phone, further for a monitor — which is precisely why it cannot equal a device pixel.
• The device pixel is one addressable dot on the display. devicePixelRatio is the number of device pixels per CSS pixel along one axis, and it is the *product* of the display's density and the current browser zoom.
• The layout viewport is the box your layout is laid out into and what width media queries measure. The visual viewport is the part of it the user can currently see. Pinch zoom shrinks the visual viewport within an unchanged layout viewport; browser zoom shrinks the layout viewport itself.
• <meta name="viewport" content="width=device-width, initial-scale=1"> says: make the layout viewport the width of the device in CSS pixels, and start at a scale of 1. Without it, mobile browsers default to a wide layout viewport and scale down.
• user-scalable=no and maximum-scale=1 cap or disable the visual-viewport zoom. Some browsers now ignore them precisely because they were so widely misused, which means the tag is both harmful and unreliable (The Accessibility Tree).
• The visualViewport API exposes the visual viewport's offset, size and scale, and fires events when it changes — which is how a page correctly positions a floating element when an on-screen keyboard opens or a user pinches.

1<!-- The whole tag. This is all most pages need. -->
2<meta name="viewport" content="width=device-width, initial-scale=1">
3 
4<!-- Blocks or caps pinch zoom. Do not ship this. Some browsers ignore it,
5     which means it is both harmful and unreliable. -->
6<meta name="viewport"
7      content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
8 
9<!-- Only when the page genuinely paints under a notch or home indicator,
10     and only together with the safe-area insets. -->
11<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
12<style>
13  .app { padding-inline: max(1rem, env(safe-area-inset-left)); }
14</style>

Layout                     CSS px   DPR   Device px   srcset picks
----------------------------------------------------------------------
Phone, 3x display, full-bleed   390     3        1170     ~1200w
Phone, 2x display, full-bleed   390     2         780      ~800w
Laptop, 1x, 1440 layout        1440     1        1440     ~1440w
Laptop, 2x, 1440 layout        1440     2        2880     ~2880w
Same 2x laptop at 200% zoom     720     4        2880     ~2880w

The browser never asks "what device is this". It computes:
  layout width in CSS px  (from `sizes`)  x  devicePixelRatio
  -> a target width in device px, matched against the `w` descriptors.

Read the last two rows together. Zoom added no pixels to the screen; it
relabelled them. Half as many CSS pixels across, twice as many device
pixels per CSS pixel, the same 2880 dots — which is why devicePixelRatio
is a rendering ratio and a terrible "is this a retina device" test.

• Write exactly one viewport meta tag: width=device-width, initial-scale=1. Add viewport-fit=cover only if the page genuinely paints under a notch or a home indicator, and then handle the safe-area insets.
• Never ship user-scalable=no or maximum-scale=1. If a specific behaviour is bothering you, fix that behaviour — usually a form control font size, or a layout that assumes the visual viewport equals the layout viewport (Native Forms First).
• Size in rem for anything that should scale with the user's reading preference, and in px only for things that are genuinely device-anchored, such as a hairline border (Responsive Typography).
• Serve images by pixel budget rather than by device class: srcset already multiplies layout width by the ratio for you, which is more accurate than any devicePixelRatio branch you could write (Responsive Images).
• Use dvh / svh / lvh rather than vh where a mobile browser's collapsing toolbar matters, and understand that they are three different answers to "how tall is the viewport" rather than three spellings of one (Grid: Two Dimensions at Once).
• Listen to the visualViewport API — not window.resize — when positioning something against an on-screen keyboard or a pinched view (How an Event Is Dispatched).