orientation: requesting a PWA's default screen

In one line: The manifest orientation member requests a default screen orientation — such as portrait or landscape — for an installed web app’s top-level windows, subject to what the browser and device actually honor.

Where it is supported

• Legend
• Yes
• Partial
• Flag
• No
• Unknown

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Desktop)	Yes	39	high	source	—
Chrome (Android)	Yes	39	high	source	1
Edge (Desktop)	Yes	79	high	source	2
Firefox (Desktop)	No	—	high	source	3
Firefox (Android)	Yes	79	high	source	—
Safari (macOS)	No	—	high	source	4
Safari (iOS)	No	—	high	source	56
Samsung Internet	Yes	4.0	high	source	7
WebView (Android)	Yes	39	high	source	8

1. Derived by browser-compat-data mirroring from Chrome.
2. Derived by browser-compat-data mirroring from Chrome.
3. No Firefox support is recorded in browser-compat-data.
4. No Safari support is recorded in browser-compat-data.
5. No Safari on iOS support is recorded in browser-compat-data.
6. Derived by browser-compat-data mirroring from Safari.
7. Derived by browser-compat-data mirroring from Chrome Android.
8. Derived by browser-compat-data mirroring from Chrome Android.

Source data: /compatibility/manifest-orientation.json · Global usage: 74 % (StatCounter 2026-05)

Source: spec · MDN · Last verified 2026-10-03 · Confidence: high (computed from sources)

Per MDN and the spec, orientation support and behavior are conditional on the browser and device honoring the requested value — treat this as a preference, not a guarantee.

How to use it

Declare the member in the web app manifest with one of the spec’s keyword values:

{
  "name": "Field Journal",
  "start_url": "/",
  "display": "standalone",
  "orientation": "portrait"
}

Accepted values per the spec include any, natural, landscape, landscape-primary, landscape-secondary, portrait, portrait-primary, and portrait-secondary.

How to detect it at runtime

The manifest orientation member sets the default orientation, which can be overridden at runtime through other means, including the Screen Orientation API. The separate API’s lock() method has limited browser support, so feature-detect it before calling it and keep the layout adaptable when the method is absent or the call is rejected:

function supportsOrientationLock() {
  return 'orientation' in screen && typeof screen.orientation.lock === 'function';
}

async function lockPortrait() {
  if (!supportsOrientationLock()) {
    return; // no lock API on this browser: fall back to the responsive layout below
  }
  try {
    await screen.orientation.lock('portrait');
  } catch {
    // handle rejection — lock() has limited browser support
  }
}

/* Fallback: adapt the layout with CSS instead of assuming either orientation
   mechanism took effect. */
@media (orientation: landscape) {
  .journal-entry {
    grid-template-columns: 1fr 1fr;
  }
}

What goes wrong

• Per MDN and the spec, support for individual orientation values can vary by browser and device; the user agent attempts to honor the requested value but isn’t guaranteed to for every value it accepts.
• MDN describes the manifest orientation as a preference the browser or OS attempts to honor, and separately documents the Screen Orientation API as a way to change orientation at runtime — the two are related but distinct mechanisms.
• Per MDN, omitting orientation typically falls back to the device’s natural orientation together with the user’s or system’s own orientation settings, not a simple, guaranteed passthrough of “natural orientation” alone.
• The manifest orientation member and the separate Screen Orientation API (screen.orientation) are independent capabilities — a user agent can support one without the other.

Where to go next

• Web App Manifest: orientation support — browser support matrix
• Manifest display modes: standalone vs fullscreen — the display mode this orientation request applies within