iPhone Duo and CSS breakpoints: your framework thinks it is a phone

Tailwind CSS has four breakpoints above its base tier. The smallest, sm, is 640px.

The iPhone Duo’s inner display is 626 CSS pixels wide.

It misses by fourteen.

That is the whole of this article in three lines, but the consequence is worth spelling out: on a Tailwind site with default breakpoints, Apple’s 7.6-inch folding display gets exactly the same CSS as a 6.3-inch iPhone. Not a similar layout. The same one, because no media query between the two widths ever matches.

We checked five widely used CSS frameworks and four large sites to see how general that is. Three of the five frameworks do the same thing.

Where 626 comes from

Apple publishes the inner display in pixels: 1878 × 2670. The device is @3x, so the point dimensions are 626 × 890, and CSS pixels correspond to points. A page on the unfolded display therefore gets a viewport about 626 CSS pixels wide, and devicePixelRatio reports 3.

The arithmetic, and why sources disagree about it, is in points vs pixels. The full table is on the display reference. The closed outer display is 466 CSS pixels, which matters later.

The five frameworks

Each figure below was read from the project’s own published source on 7 October 2026, not from documentation or memory. The commands are in the methodology at the end, so you can re-run any of them.

Three of five serve 626 the same tier they serve a phone.

Tailwind and Foundation miss by the same fourteen points, which is a coincidence worth noticing: both chose 640, the width of a 1990s VGA display, and Apple chose a panel whose point width lands just under it.

The two that do differentiate are only a partial comfort. Bootstrap’s sm starts at 576 and is documented as the landscape phone tier; MUI’s sm starts at 600, and its first genuinely wide tier, md, does not arrive until 900. Neither gives 626 a tablet layout. They give it a slightly roomier phone one.

What “the same tier” actually costs

A 626-point-wide regular-width display rendering a layout designed for 390 points means single-column content, a hamburger menu where a navigation bar would fit comfortably, and body text stretched to a measure chosen for a screen 236 points narrower. Nothing is broken. Nothing throws. It simply looks like a phone layout that has been stretched, which is the thing users notice immediately and developers often do not, because the simulator screenshot still looks fine.

The outer display is the unanimous one

At 466 CSS pixels, the closed display falls in the same tier as a 390px phone in all five frameworks. That is the right answer for four of them and the interesting part is not the tier but the number.

466 is wider than an iPhone 18 Pro, which is 402 points. So the outer display is not a small screen receiving a small-screen layout; it is a wider-than-usual phone screen receiving a layout tuned for a narrower one. The failure mode there is different: stretched touch targets, over-long line lengths, and hero images cropped to the wrong focal point.

The counter-finding: large sites already handle this

We expected to find big sites failing too. They mostly do not.

Of twelve sites we loaded at 626 × 890, four met our inclusion rule — every stylesheet readable, so coverage was complete rather than partial. All four have a breakpoint boundary between 390 and 626, so none of them serves the inner display the phone stylesheet:

Four sites is an illustration, not a survey, and we say so plainly. But the direction is consistent and it makes sense: organisations with a design system and a performance budget end up with many breakpoints, and a dense enough set catches 626 by accident.

The risk is not there. It is in the enormous number of sites that install a framework, never touch screens or $grid-breakpoints, and ship. For those, 626 is not an edge case anybody decided about. It is a gap nobody knew existed.

What to do about it

Do not add a 626px breakpoint. It is the wrong fix and it dates instantly — the viewport changes while the page is open, as the device folds, and the next foldable will have different numbers.

Three better moves, in order:

1. Check what happens in the gap. Resize to 626 and then to 466. If the layout at 626 is identical to the layout at 390, you have found the problem and you now know its size.
2. Add a range, not a device width. If your framework’s first step is 640, something in the 560–720 region is doing nothing for a real display. Pick a boundary based on where your content wants to reflow, not on a device.
3. Prefer container queries where you can. A component that responds to its own container does not care what the device is, which is the only approach that survives a screen that resizes mid-session.

One thing none of this fixes: CSS cannot see the fold. Chrome shipped the Viewport Segments API; Safari has not, and WebKit has recorded no position on it. So you can respond to the width change and not to the crease running through your layout. That gap, and what to do about it, is websites on iPhone Duo.

Check your own site in thirty seconds

Paste this into DevTools on any page. It prints every width breakpoint your CSS actually defines, and whether 626 and 466 land in the same band as a phone:

const bp = new Set();
let read = 0, total = 0;
for (const sheet of document.styleSheets) {
  total++;
  try {
    const walk = (rules) => {
      for (const r of rules) {
        const m = r.media && (r.conditionText || r.media.mediaText);
        if (m && /width/.test(m)) {
          for (const [, n, unit] of m.matchAll(/(\d+(?:\.\d+)?)(px|rem|em)/g)) {
            bp.add(Math.round(unit === 'px' ? +n : +n * 16));
          }
        }
        if (r.cssRules) walk(r.cssRules);
      }
    };
    walk(sheet.cssRules);
    read++;
  } catch { /* cross-origin stylesheet */ }
}
const sorted = [...bp].sort((a, b) => a - b);
const band = (w) => sorted.filter((v) => v <= w).pop() ?? 0;
console.log({
  stylesheetsRead: `${read}/${total}`,
  breakpoints: sorted,
  innerDisplayGetsPhoneCSS: band(626) === band(390),
  outerDisplayGetsPhoneCSS: band(466) === band(390),
});

Watch the stylesheetsRead ratio. Anything less than the total means CORS blocked a cross-origin stylesheet and the result is incomplete — which is the single easiest way to get this wrong.

There is a second trap. Chrome normalises media queries to the CSS range syntax, so a rule authored as @media (min-width: 768px) comes back as (width >= 768px). Grep for min-width and you will find nothing on a site that is full of breakpoints. We lost a measurement pass to exactly that.

Methodology

Framework figures, 7 October 2026. Tailwind was read from the package installed in this site’s own node_modules; the rest from their published distributions:

grep breakpoint- node_modules/tailwindcss/theme.css
curl -sL https://cdn.jsdelivr.net/npm/bootstrap@5/dist/css/bootstrap.min.css | grep -oE "min-width:[0-9.]+px" | sort -u
curl -sL https://cdn.jsdelivr.net/npm/bulma/css/bulma.min.css | grep -oE "min-width:[0-9.]+px" | sort -u
curl -sL https://cdn.jsdelivr.net/npm/foundation-sites/dist/css/foundation.min.css | grep -oE "min-width:[0-9.]+em" | sort -u
curl -sL https://unpkg.com/@mui/system/createBreakpoints/createBreakpoints.js | grep -oE "(xs|sm|md|lg|xl): *[0-9]+"

Site figures were taken in a Chromium browser at a 626 × 890 viewport with a mobile user agent, using the snippet above. Twelve sites were loaded; eight were discarded because at least one stylesheet was cross-origin and unreadable, the page served a bot-challenge shell, or the host refused the request. We report the four where coverage was complete rather than the eight where it was not, because a partial stylesheet read produces a confidently wrong answer.

The table lists each framework’s documented tier boundaries, which are what a developer configures. The greps also surface a handful of component-level queries below 400px – Bootstrap has one at 85px, Bulma one at 300px and Foundation one at 2.1em – which we left out because they sit below both widths being compared and so cannot change the result.

Two caveats on the numbers themselves. Breakpoints authored in em are resolved against the browser’s initial font size, so the 640px figures for Tailwind and Foundation assume the 16px default and move if a reader has changed it. And a desktop Chromium at 626px is not an iPhone Duo: it is the same viewport width, which is all this measurement depends on, but user-agent sniffing means the HTML a site serves a real device may differ from what it served us.

If you would rather have someone else establish which of these applies to your site and what it would take to fix, that is what an audit covers.