Designing for Foldable Phones with the Device Posture API

A foldable phone can switch from a flat screen to a partially folded one without changing devices or reloading your page. The Device Posture API gives web apps two posture values, `continuous` and `folded`, through CSS and JavaScript. It describes how the viewport is being used, not the phone model or an exact hinge angle.

That distinction matters. A regular phone reports `continuous`, but so can a foldable that is fully open or showing your app on only one side of its hinge. Don't use this API to identify a foldable phone; use it to adapt an interface when the browser reports a folded posture.

Start with a layout that works everywhere

For the exact posture definitions and browser behavior, consult the W3C Device Posture specification.

Consider a reading app with an article and a notes panel. The base layout stacks both regions on a narrow screen and places them side by side when there is room. Posture is an enhancement, not a prerequisite.

<div class="reader">
  <main class="article">
    <h1>Field notes</h1>
    <p>Your article content goes here.</p>
  </main>
  <aside class="notes" aria-label="Notes">
    <h2>Notes</h2>
    <p>Related notes go here.</p>
  </aside>
</div>
<p id="posture-status" role="status"></p>

.reader {
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  gap: 1.5rem;
}

.reader > * { min-width: 0; }

@media (min-width: 48rem) {
  .reader { grid-template-columns: minmax(0, 2fr) minmax(0, 1fr); }
}

/* A useful enhancement when the browser reports a folded posture. */
@media (device-posture: folded) {
  .reader { gap: 3rem; }
}

The `device-posture` media feature accepts `folded` and `continuous`. This example adds breathing room when folded, but the larger gap is an approximation; posture alone does not tell us where a physical hinge falls within the viewport.

React to a posture change in JavaScript

CSS handles layout. JavaScript is useful if a posture change should update interface state, such as a status message or a reading-mode control. Read the initial value, then listen for `change`. Feature detection keeps the page working where the API is unavailable.

const status = document.querySelector("#posture-status");
const posture = navigator.devicePosture;

if (posture && status) {
  const updateStatus = () => {
    status.textContent = posture.type === "folded"
      ? "Folded view"
      : "Flat view";
  };

  updateStatus();
  posture.addEventListener("change", updateStatus);
}

In an app with mounted and unmounted components, remove the listener during cleanup. The API is exposed in secure contexts, so test from HTTPS or a suitable local development origin.

When the hinge position matters, use viewport segments

A generous gap cannot guarantee that text avoids a hinge. The separate Viewport Segments API reports whether the viewport has distinct regions and exposes their dimensions and positions. For a browser reporting two side-by-side segments, you can place each pane in its own region.

/* Apply after the base .reader styles above. */
@media (horizontal-viewport-segments: 2) {
  .reader {
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
    column-gap: calc(
      env(viewport-segment-left 1 0) -
      env(viewport-segment-right 0 0)
    );
  }
}

The `0 0` and `1 0` coordinates select the left and right segments. The calculated gap represents the space between them. This is a separate capability from posture detection, so check it independently rather than assuming every browser with `device-posture` also exposes segment geometry.

Ship it as progressive enhancement

Both the Device Posture API and viewport-segment features have limited browser availability and are marked experimental by MDN. Keep the ordinary responsive layout usable first. Then test a flat phone, a wide display, a folded device, and a browser without the APIs. Also test on physical hardware where possible: MDN notes that current foldable emulation may not reproduce partially folded posture or actual viewport segments.

The practical rule is straightforward: use width for available space, posture for a change in how the device is held, and viewport segments when you need to place content around a real split.

For viewport geometry and browser support, consult the MDN Viewport Segments API reference.