Web design for foldable phones: sizes, folds and tips

A foldable phone gives your website two completely different viewports. Folded, it's a narrow phone: 369 to 444 CSS pixels wide on the Android cover screens, and about 382 usable on the iPhone Duo's outer screen. Unfolded, it's a small tablet, near-square on Samsung and Google foldables (708 to 755 px wide) or landscape on the iPhone Duo (951 × 669). Unfolding normally resizes the page rather than reloading it, so your layout has to work in both states and survive the jump between them.

The foldables and their viewports

Here's every foldable screen we track, with its CSS viewport, device pixel ratio and physical resolution:

Paired up, the jump from folded to open looks like this:

The Galaxy Z Flip is the odd one out. It folds top to bottom, and open it's simply a tall phone: 412 × 960 for the Z Flip 7 and 412 × 1006 for the Z Flip 6. Design for it like any other phone, just a tall one.

Some of these numbers (the Fold 6, the Pixel 10 Pro Fold and the Flips) are derived from the panel resolution rather than measured on a device, and their device pages mark them as estimates. The iPhone Duo's numbers come from Apple's iOS 27.1 simulator. Its outer screen loses 84 px to a system strip, which gets its own article: iPhone Duo for web developers. All of them live on the foldables hub.

What changes when someone unfolds

A brand-new viewport, mid-visit

Unfolding a Galaxy Z Fold 7 takes the page from 412 to 750 px wide while the visitor is on it. The browser fires a resize event, re-runs your media queries and recalculates vw, vh and container sizes. That's the good news: CSS handles it for free.

JavaScript often doesn't. Anything that read window.innerWidth once at page load (a carousel that counted how many slides fit, a canvas sized on startup, a "mobile menu" flag) is now wrong. Listen for changes instead:

const wide = window.matchMedia('(min-width: 700px)');

function applyLayout(isWide) {
  // rebuild the carousel, resize the chart, switch the menu, etc.
}

applyLayout(wide.matches);
wide.addEventListener('change', (e) => applyLayout(e.matches));

For a single component, ResizeObserver is often better, because it reacts to the element's own size rather than the window's:

const chart = document.querySelector('.chart');

new ResizeObserver(([entry]) => {
  drawChart(entry.contentRect.width); // your own drawing function
}).observe(chart);

Layouts jump between breakpoints, or fail to

Here's the trap. The unfolded Galaxy and Pixel screens (708 to 755 px) sit just below the most common tablet breakpoint: Tailwind's md and Bootstrap's md both start at 768 px.

So on an unfolded Fold 7, a site built with default breakpoints shows its phone layout stretched to 750 px: one column, huge images, and lines of text far too long to read comfortably. The iPhone Duo's inner screen (951 px) does cross md, but stays under Tailwind's lg (1024) and Bootstrap's lg (992), so it gets your tablet layout on a screen that's only about 589 px tall once Safari's toolbar is in.

The fix is to add breakpoints where your content needs them, often somewhere around 600 to 700 px, not where a framework's defaults happen to sit, and to cap line length. Tailwind breakpoints on real devices and responsive breakpoints in 2026 show where real screens land.

State and scroll position get shaken

When the page gets wider, text reflows and everything above the reader gets shorter, so the paragraph they were reading can jump away. It gets worse if your code swaps whole components at a breakpoint (unmounting the phone menu and mounting a desktop one, say), because open menus, half-filled forms and scroll positions inside them are lost. Restyle components with CSS where you can, rather than replacing them.

The fold itself

On book-style foldables (Galaxy Z Fold, Pixel Fold, iPhone Duo), the inner screen is one continuous panel with a crease down the middle. By default, browsers treat it as one ordinary viewport: your page runs straight across the crease.

• Fully open, the crease catches the light, but people read across it without trouble.
• Half open, propped up like a tiny laptop or held like a book, whatever sits in the middle bends away from the reader. A centred video, or a button in the exact middle of the screen, lands right on the fold.

On the iPhone Duo, the crease sits at about x = 475.5, the exact middle of its 951 px page.

The fold APIs (experimental)

Two newer web APIs let a page find out about the fold. Both are experimental: not supported across the major browsers, not part of Baseline, and not available by default in Safari on the iPhone Duo. Treat them as progressive enhancement, never as a requirement.

Viewport Segments

The Viewport Segments API tells you when the viewport is split into parts by a fold, and where each part is. Two segments side by side (a vertical fold) match horizontal-viewport-segments: 2:

@media (horizontal-viewport-segments: 2) {
  .layout {
    display: grid;
    grid-template-columns: env(viewport-segment-width 0 0) 1fr;
    column-gap: calc(env(viewport-segment-left 1 0) - env(viewport-segment-right 0 0));
  }
}

The first column fills the left segment exactly and the gap covers the fold, so nothing sits on the crease. In JavaScript, window.viewport.segments returns an array of rectangles, one per segment. The spec is part of the CSS Viewport module.

Device Posture

The Device Posture API reports whether the screen is flat (continuous) or bent (folded):

@media (device-posture: folded) {
  .player-controls {
    /* e.g. move the controls to the lower half */
  }
}

if ('devicePosture' in navigator) {
  navigator.devicePosture.addEventListener('change', () => {
    console.log(navigator.devicePosture.type); // "continuous" or "folded"
  });
}

The W3C Device Posture spec has the details. Because support is patchy, your page has to work perfectly without either API.

Design tips that work on every foldable

1. Go fluid, not fixed. Let grids pick the number of columns from the space available:

   .cards {
     display: grid;
     grid-template-columns: repeat(auto-fit, minmax(min(100%, 280px), 1fr));
     gap: 1rem;
   }
   

   That's one column on a 369 px cover screen and two on a 750 px inner screen, with no breakpoints at all. The min(100%, 280px) stops cards from overflowing on very narrow screens.

2. Don't assume one aspect ratio. The Fold 7's inner screen is slightly tall (750 × 832), the Pixel Fold's almost square (755 × 783) and the iPhone Duo's landscape (951 × 669). @media (orientation: landscape) matches on the Duo's inner screen even though nobody rotated anything, so rules like "landscape means a phone on its side, so shrink the header" misfire. Use width and height queries for layout decisions.

3. Cap line length. max-width: 65ch on text blocks keeps a 750 px wide column readable.

4. Don't size heroes with 100vh. Short, wide screens make the classic mobile 100vh problem worse; use svh or dvh (the 100vh fix).

5. Test the narrow cover too. The Fold 6 cover is 369 px wide, narrower than an iPhone SE's 375. Fixed widths that squeak by on other phones overflow there; fix horizontal scrolling on mobile shows how to find them.

6. Keep state across the resize. Forms, open menus and scroll position should survive someone unfolding the phone halfway through a task.

7. Test both states side by side. In doesitfit, the "Android flagships" set includes the Fold 7 cover and unfolded screens, and "iPhone 18 & Duo" loads both Duo screens with mockups. Turn on Browser bars to see the height Safari and Chrome leave you.

Your foldable checklist

• Check every key page at a cover size (369 to 444 px) and an unfolded size (708 to 755 px, plus 951 × 669 for the iPhone Duo).
• Make sure 700 to 767 px doesn't show a stretched phone layout.
• Replace one-off innerWidth reads with matchMedia or ResizeObserver.
• Use the fold APIs as a bonus, never a requirement.