We ran one ordinary page through three browser engines, seven window sizes and two text sizes, then ranked the checks by what they found.
Your browser’s controls
These controls have no CSS applied. The sizes come from the browser you are reading this in, so you can compare them with the three engines further down.
Measuring the controls in your browser.
What the run found
We built one page with a sticky header, a card grid, a web font, a form, a one-line filter row, a pricing table and a native modal. Its CSS uses common patterns that often break, such as fixed heights, 100vw and white-space: nowrap, so expect it to fail more than a carefully built page would. It ran in Chrome, Firefox and WebKit at seven window sizes, with normal text, with 200 percent text and with the web font blocked. That made 77 runs and 16 distinct problems.
| Problem | Runs | Normal text | Widest window | Engines |
|---|---|---|---|---|
| In-page link lands under the sticky header | 77 of 77 | Yes | 1920 | All three |
| Page behind the modal scrolls | 72 of 77 | Yes | 1920 | All three |
| Shift+Tab puts focus under the sticky header | 38 of 42 | Yes | 1920 | All three |
| Modal submit button needs scrolling to reach | 53 of 77 | Yes | 1920 | All three |
| Filter row wider than the window | 52 of 77 | Yes | 1280 | All three |
| Header wider than the window | 40 of 77 | Yes | 1280 | All three |
| Table wider than the window | 37 of 77 | Yes | 844 | All three |
| Text spills out of the fixed-height header | 35 of 77 | Only at 200% | 1920 | All three |
| Full-width band wider than the window | 28 of 77 | Yes | 1920 | Chrome |
| Text spills out of the fixed-height band | 15 of 77 | Only at 200% | 640 | All three |
| Long URL wider than the window | 12 of 77 | Yes | 640 | Chrome, WebKit |
| Card grid wider than the window | 10 of 77 | Only at 200% | 390 | All three |
| Footer wider than the window | 10 of 77 | Only at 200% | 390 | All three |
| Form wider than the window | 7 of 77 | Only at 200% | 640 | All three |
| Unstyled controls wider than the window | 7 of 77 | Only at 200% | 390 | All three |
| Heading word wider than the window | 5 of 77 | Only at 200% | 320 | All three |
The in-page link failed in every run. The browser scrolled the heading to the top of the window, where about 64 pixels of it sat behind the header. The filter row did the most sideways damage, because a flex row with two date inputs and a long select won’t wrap unless you tell it to. In Chrome it pushed the page 563 pixels past the edge of a 320 pixel window.
How much each pass finds
A desktop browser at normal text size found the fewest. Every problem that appeared at normal text also appeared at 200 percent, so the larger text size replaces a separate pass.
| Pass | Problems found |
|---|---|
| Chrome, 1280 wide, normal text | 4 of 16 |
| Chrome, all seven windows, normal text | 9 of 16 |
| Firefox, all windows, both text sizes | 14 of 16 |
| WebKit, all windows, both text sizes | 15 of 16 |
| Chrome, 320 wide, 200% text | 16 of 16 |
A window 320 pixels wide is also the size WCAG 1.4.10 uses for reflow, and 200 percent is the figure in WCAG 1.4.4, so the same pass covers both. If your text doesn’t scale at all, start with accessible font sizing.
This is one page, so treat the order as a starting point. A site with engine-specific CSS or scripts could turn up problems that no single browser shows.
Where the engines differed
Sizes are CSS pixels, read with the window 1280 wide unless the row says otherwise. Control sizes are width by height.
| Measurement | Chrome | Firefox | WebKit |
|---|---|---|---|
| Sideways overflow at 320 wide, normal text | 563 | 535 | 264 |
| Sideways overflow at 320 wide, 200% text | 1379 | 1292 | 812 |
| Scrollbar width | 15 | 0 | 0 |
| Tab stops on the page | 64 | 65 | 29 |
| Date input | 116.33 x 21.33 | 119.67 x 21 | 152 x 22 |
| Select | 48 x 19 | 53.9 x 22 | 51 x 28 |
| File input | 253 x 21 | 230.65 x 22 | 221 x 25 |
| Range slider | 129 x 16 | 160 x 20 | 129 x 20 |
| Checkbox | 13 x 13 | 14 x 14 | 12 x 12 |
| Text input | 177 x 21 | 164.67 x 22 | 152 x 22 |
The WebKit column needs care. This Windows build of WebKit has no date control, so type="date" came back as text and took one Tab stop where Chrome and Firefox took four. That probably explains why the filter row fitted in WebKit at 640 to 844 pixels wide and overflowed in the other two: a text box can shrink further than a date control can.
WebKit also stopped only on buttons and form fields, skipping all the links, which accounts for 29 Tab stops against 64 in Chrome. Safari has a setting for this, “Press Tab to highlight each item”, so a keyboard test there needs that setting on (Apple’s page, checked 8 November 2026).
The full-width band showed up only in Chrome, and scrollbars are the reason. 100vw includes the scrollbar, and Chrome was the only engine where the scrollbar took up space in this run. With Chrome’s scrollbars hidden the overflow went away. With Firefox’s overlay scrollbars turned off, its scrollbar took 17 pixels and the page overflowed by 9. Firefox also kept the long URL inside the window at every size where Chrome and WebKit let it stick out.
Photo by Mike ArtKeyboard and modals
Pressing Tab forwards never put focus under the sticky header, in any of 42 walks through the page. Shift+Tab did so in 38 of them, because the browser scrolls the element to the top edge when you move up the page. In 34 of those runs at least one focused element was completely covered, which fails WCAG 2.4.11.
The native dialog element held up well. Escape closed it, focus went back to the button that opened it, and Tab never reached the page behind, in all 119 runs. The page behind the modal did scroll with the mouse wheel, in 72 of 77 runs. The five exceptions were all WebKit, and we can’t explain the pattern. At normal text the submit button was out of view on opening only in windows 568 pixels tall or shorter, so a short window is the one to test.
The checklist, in order
- Set one browser to 320 pixels wide with text at 200 percent. In Chrome, use the device toolbar and set Font size to 32 in
chrome://settings/fonts. Look for anything that scrolls sideways or spills out of its box. - Click every in-page link and check that the target isn’t under a sticky header.
- Go to the bottom of the page and press Shift+Tab all the way up, watching the focus.
- Open each modal in a window about 844 by 390. Reach the last button, press Escape, and try scrolling the page behind it.
- Repeat step 1 somewhere the scrollbar takes up space, to catch
100vw. - In a second engine, check forms and filter rows, especially date inputs, and the Tab order. See how the engines compare.
- Block the web font once. In our run this changed the page height by at most 87 pixels and caused no new problems, so it comes last.
When something breaks in only one browser, cut it down to a reduced test case before you start changing CSS.
The CSS that cleared it
We added these rules to the same page and ran it again at all seven sizes.
html { scroll-padding-top: 8rem; }
html:has(dialog[open]) { overflow: hidden; }
body { overflow-wrap: anywhere; }
.site { height: auto; min-height: 64px; flex-wrap: wrap; padding-block: .5rem; }
@media (max-width: 1023px), (max-height: 500px) { .site { position: static; } }
.site nav ul { flex-wrap: wrap; }
.btn { white-space: normal; }
.band { width: auto; margin-left: 0; height: auto; min-height: 160px; }
.grid { grid-template-columns: repeat(auto-fit, minmax(min(17.5rem, 100%), 1fr)); }
.filters, .foot { flex-wrap: wrap; }
.field, .filters > * { min-width: 0; max-width: 100%; }
input, select, textarea, progress, meter { max-width: 100%; }
table { display: block; overflow-x: auto; }Across 42 more runs, sideways overflow disappeared except in WebKit at 320 wide with 200 percent text, where the form stayed 15 pixels too wide. The modal button still needed scrolling in 30 runs, which is fine when the modal is taller than the window and scrolls. Focus went under the header in 3 runs and an in-page link in 1, all with 200 percent text at 1280 wide or more.
Turning sticky off in small windows is deliberate. Once the header could wrap, it grew to 293 pixels in a window 390 tall, which is 75 percent of the screen.
How this was tested
A script loaded the page from a local server on 8 November 2026 on Windows 11, headless, and recorded element positions, overflow, focus order and modal behaviour.
- Chrome 156.0.8078.80 and Firefox 159.0.1.
- WebKit 26.0 from Playwright 1.56.1. This build is not Safari, and nothing here ran on an iPhone or any other phone.
- Windows of 320 by 568, 390 by 844, 844 by 390, 640 by 400, 768 by 1024, 1280 by 800 and 1920 by 1080.
The 200 percent text in the tables comes from html { font-size: 200% }, because this WebKit build has no font size setting. In Chrome and Firefox we also set the real default font size to 32. Overflow, grid columns and line counts matched the CSS rule in 14 of 14 comparisons, though unstyled form controls only grew with the real setting. Browser zoom was not driven directly: 640 by 400 stands in for a 1280 by 800 window at 200 percent zoom.
The full output is available as raw JSON. The test script and this article were prepared with help from AI.
Common questions
Do I need to test every browser?
Each engine alone found at least 14 of the 16 problems here. Use the others for form controls, keyboard order and anything engine-specific in your code.
Is Playwright’s WebKit the same as Safari?
No. In this run its date input was a plain text box. Use it to catch engine differences early, and use a real Apple device before you rely on a result.
How many screen sizes are enough?
For layout, 320 wide found everything here. Add one short window such as 844 by 390 for modals and sticky headers.