You review the site on your laptop. It looks right. You send it off. Two days later a client or a teammate on a different monitor says the layout is "off" — and you can't reproduce it, because on your screen, it isn't.
This isn't a browser bug and it isn't your client being difficult. It's the most common blind spot in website QA: testing on one screen and assuming that proves the design works on all of them.
It's not the device. It's the viewport.
A responsive layout doesn't know what device it's on — it only knows one number: the width of the browser window, in CSS pixels. That number is called the viewport, and it changes for reasons that have nothing to do with "desktop vs. mobile":
- Window size — a browser window snapped to half a screen reports a completely different width than the same window maximized.
- Monitor resolution and OS display scaling — a 27" external display at 1440p with 100% scaling reports a much wider viewport than a MacBook's built-in Retina screen, even though both are "just a laptop and a monitor."
- Browser zoom — zooming to 90% or 125% changes the effective viewport width exactly like resizing the window does.
Two people on the exact same browser, the exact same website, can see two different layouts — because the layout was never responding to "the browser." It was responding to a width, and their widths are different. That's why a site can look flawless on a designer's laptop and visibly break on a client's ultrawide monitor: nobody did anything wrong, the site just was never tested at that width.
This is also more common than most teams assume. According to StatCounter, the single most common desktop screen resolution worldwide (1920×1080) accounts for only around 20% of desktop traffic — meaning roughly 4 out of 5 desktop visitors are on some other resolution entirely. There is no one "normal" screen to design for.
The breakpoints every framework actually uses
If you build on Webflow, Tailwind, or Bootstrap, your site already snaps to a specific set of breakpoints — worth knowing exactly where they are, because that's exactly where things break:
- Bootstrap 5: sm 576px, md 768px, lg 992px, xl 1200px, xxl 1400px
- Tailwind CSS: sm 640px, md 768px, lg 1024px, xl 1280px, 2xl 1536px
- Webflow: Mobile Portrait ≤479px, Mobile Landscape 480–767px, Tablet 768–991px, Desktop 992px+ (with optional larger canvases at 1440px and 1920px)
Notice where they disagree: every framework treats roughly 768px as the tablet line, but the tablet-to-desktop handoff drifts anywhere from 992px to 1024px depending on the tool. That 30–60px gap is a dead zone few people ever actually test — and it's exactly where "desktop" navs collapse too early or "tablet" layouts stretch too far.
How to actually test it before launch
- 1Test the in-between widths, not just the presets. 900px, 1024px, 1100px, 1440px — most real breakage happens at the seams between breakpoints, not inside them.
- 2Test on a real large external monitor, not just a resized browser window. OS-level display scaling changes the effective viewport in ways devtools resizing doesn't replicate — this is exactly the "MacBook vs. external monitor" gap.
- 3Test landscape orientation on tablets and phones. A phone turned sideways can be wide enough to accidentally trigger the tablet layout.
- 4Test with browser zoom at 90% and 125%, not just 100%. Zoom changes the reported viewport width the same way resizing does.
- 5Test OS-level accessibility text scaling, not just browser zoom — some layouts hold up fine under browser zoom and still break under a client's enlarged system font settings.
- 6Do final QA on a real device where you can, especially for mobile Safari — devtools emulation approximates viewport size but not real touch behavior, on-screen keyboards, or rendering quirks.
Pick real widths, not guesses
The fix isn't "test on more devices" in the abstract — it's reviewing the site at specific, fixed widths that match how people actually view it, on the same screen every time, so a QA pass is reproducible instead of "looked fine when I checked." A live review with a device switcher fixed at 1280px, 1440px, and 1920px catches the exact laptop-vs-monitor gap above, because everyone reviewing is looking at the same width regardless of what physical screen they're sitting at.
Review the live site at fixed desktop widths, tablet, and phone sizes in one link: The website feedback tool for live pages →
Pin whatever you find directly on the element at that width, and it becomes a task automatically — so "the spacing breaks at 1440px" is a comment on the exact spot, not a bug report someone has to go hunt for.