Device Viewport Database

Start by choosing categories, not favorite brands. A strong first pass usually includes one compact phone viewport, one larger mobile or foldable reference, one tablet-style layout, one mainstream laptop-width browser, and one wider desktop or monitor case. That mix catches far more layout behavior than a random set of similar devices with only small differences between them.

Use CSS viewport width as the first filter because that is what most responsive breakpoints actually react to. Width tells you where nav bars wrap, cards stack, filters compress, and tables start overflowing. Then bring in viewport height when your page depends on above-the-fold composition, sticky headers, long forms, mobile keyboards, or bottom action bars that compete for vertical space.

Resolution, DPR, and PPI matter after the layout baseline is chosen. Those values explain why screenshots can look sharper, softer, denser, or more crowded than another device with similar CSS space. They are especially useful when design, QA, and product are all looking at the same screen capture but disagreeing about whether the issue is spacing, density, or image quality.

The family pages and comparison pages are what turn the table into a workflow. Use a family page when you need to stay inside one platform, and use a comparison page when you need to justify why one record should replace another in a test matrix. That keeps your shortlist grounded in named references instead of habit, assumptions, or whichever device happens to be available first.

By the time you reach sign-off, the database should have done one thing well: reduce guesswork. A release plan is easier to trust when the chosen devices came from a clear width, height, density, and category spread, and when those records are paired with live browser measurements rather than treated as static truth on their own.

Start with one tight mobile reference, one wider mobile or foldable reference, one tablet-style viewport, and one desktop or laptop-width record. That mix gives you a practical minimum set for spotting navigation wrapping, card compression, modal overflow, table pressure, and above-the-fold spacing changes before you expand into a larger matrix.

Use device family pages when you already know the platform matters. If the issue is iPhone-specific, an iPhone family page gives you a faster way to compare nearby models than jumping randomly across the full dataset. If the problem is broader, come back to the full database so you can compare cross-family behavior instead of assuming every layout problem is tied to one brand.

Keep CSS viewport values at the center of the decision, then add DPR, physical resolution, and PPI when image quality or screenshot behavior matters. Those extra fields are especially useful when a page appears sharper, softer, denser, or more spacious than another device with a similar layout width. They help explain why two devices that look close in CSS can still feel very different in practice.

Use the exports when your workflow needs the same records in planning docs, QA checklists, or spreadsheets, but keep the website open when context matters. The device detail pages, comparison library, and live checker turn raw numbers into a decision path, which is usually what teams need when they are prioritizing breakpoints or deciding which devices belong in a release sign-off.

Desktop scaling, browser zoom, browser chrome, mobile address bars, split view, installed extensions, and fullscreen mode can all change the usable layout area. That is true even when the underlying device model matches the record perfectly. The table gives you a clean baseline; the live check tells you what the user or tester is actually seeing right now.

That difference matters most on high-density laptops, large 4K monitors, and foldables, where the physical hardware sounds spacious but the live CSS viewport may be much tighter after scaling or multi-window use is applied. Without the live check, it is easy for teams to overestimate how much room a layout really has.

The best bug reports and release notes use both layers together. Start with the reference record so the team has a stable named device, then capture the current browser, viewport, DPR, operating system, and orientation from the live screen checker. That combination is much easier to reproduce than a screenshot alone or a hardware name without browser context.

Use the exports when you need records in spreadsheets or planning docs, but keep the website open when the meaning of the numbers matters. Device pages, comparison pages, and live diagnostics are what turn a flat export into a practical testing path that another person can follow without guessing what you meant.