Coverage
What a page can actually be opened on here
Two lists, and the difference between them is the whole point. One is hardware somebody picks up; the other is a viewport and a user-agent string driven on a desktop machine. A report says which of the two every finding came from.
Rows of the matrix
Browsers, by engine
Two browsers on one engine rarely disagree with each other, so the engine is named beside each. It is the honest way to read a coverage list: five names on three engines is three real chances of a difference, not five.
| Browser | Engine | Run on |
|---|---|---|
| Chrome | Blink | Desktop machines and Android handsets |
| Safari | WebKit | macOS, and iPhone and iPad hardware |
| Firefox | Gecko | Desktop machines and Android handsets |
| Edge | Blink | Windows desktop |
| Samsung Internet | Blink | Samsung Galaxy hardware |
Columns of the matrix
Screen widths, and why these ones
Widths are in CSS pixels, which is what a stylesheet works in. Each one is a width something in the hardware list below reports as its own, which is why they are not the round numbers a stylesheet is written against: a column nothing here can open natively would only ever be filled by emulation.
Small phone
The narrowest width worth supporting, and where a fixed element first has nowhere to go.
Native on Samsung Galaxy S22, in Chrome and Samsung Internet
Standard phone
The commonest phone width in the kit, and the one a two-up layout is most often introduced at a breakpoint too early.
Native on iPhone 14, in Safari and Chrome
Large phone
Wide enough that a phone layout starts borrowing rules from the tablet one, and narrow enough that they do not fit.
Native on Google Pixel 7a, in Chrome and Firefox
Tablet
Falls between a phone rule and a desktop rule more often than any other width, and it is where a hover-only control meets a finger.
Native on iPad (9th generation), in Safari
Desktop
Where wide layouts stretch, line lengths run past comfortable reading and a sticky column finds something to sit on top of.
Native on MacBook Air, in Safari, Chrome and Firefox
Hardware that is not a column
Three machines in the kit report a width the matrix does not have a column for. They are used in a run all the same, and a finding taken on one names that machine and its width rather than the nearest column.
- iPhone SE (3rd generation) 375 x 667
- iPhone 15 Pro Max 430 x 932
- Windows laptop 1536 x 864
A width of your own
A width outside this set can be added to an order. If your own figures show people arriving at a size that is not here, say so when you write and it goes into the quotation as another column. Where no machine in the kit opens it natively, the quotation says so and the findings from it come back marked as emulated.
Hardware
Devices somebody picks up
A page on one of these is loaded on the device itself, scrolled with a finger and typed into with the software keyboard. This is where the faults live that a desktop browser will never show you.
| Device | System and browsers | Viewport |
|---|---|---|
| iPhone SE (3rd generation) | iOS, Safari and Chrome | 375 x 667 |
| iPhone 14 | iOS, Safari and Chrome | 390 x 844 |
| iPhone 15 Pro Max | iOS, Safari and Chrome | 430 x 932 |
| iPad (9th generation) | iPadOS, Safari | 810 x 1080 |
| Samsung Galaxy S22 | Android, Chrome and Samsung Internet | 360 x 780 |
| Google Pixel 7a | Android, Chrome and Firefox | 412 x 915 |
| MacBook Air | macOS, Safari, Chrome and Firefox | 1440 x 900 |
| Windows laptop | Windows 11, Edge, Chrome and Firefox | 1536 x 864 |
A device that is not on this list is quoted for separately, and where it cannot be arranged the quotation says so plainly rather than quietly substituting a profile for it.
Software
Profiles driven on a desktop machine
A viewport, a pixel ratio and a user-agent string, set in a desktop browser. Fast, repeatable, and good at exactly one thing: how a layout reflows.
| Profile | How it is driven | Viewport |
|---|---|---|
| Small phone profile | Chrome and Edge device toolbar | 360 x 800 |
| Standard phone profile | Chrome, Edge and Firefox responsive mode | 390 x 844 |
| Large phone profile | Chrome, Edge and Firefox responsive mode | 412 x 915 |
| Tablet profile | Chrome, Edge and Firefox responsive mode | 810 x 1080 |
| Desktop profile | Chrome, Edge and Firefox responsive mode | 1440 x 900 |
What emulation cannot see
- Software keyboards, and what they cover when they open over a field.
- Touch behaviour proper: momentum scrolling, rubber-banding, double-tap zoom and the delay before a tap registers.
- Screen cut-outs, rounded corners and the safe areas a browser reserves around them.
- The browser interface itself appearing and disappearing as the page scrolls, and the viewport height changing while it does.
- Fonts, colour handling and video decoding as the device itself does them.
- How the page behaves on a slower processor than the machine running the emulation.
None of that makes emulation worthless. It makes it a first pass, and it is why a report from here always says which of the two a finding came from.
Check your website across devices
Tell us which of these matter to you, or describe who your visitors are and let a set be proposed. Either way the list goes into the quotation in writing before anything is run.