display manifest member

Limited availabilityNot supported in Firefox (Desktop)W3C

display chooses how much of the browser’s own UI an installed web app keeps when it launches. Its four values sit on a fixed fallback chain, fullscreen → standalone → minimal-ui → browser, so a mode the platform does not offer degrades to the next one down without any author intervention.

Chrome 39 on Android, Chrome 73 on desktop, Edge 79, Samsung Internet 4.0, and Safari 11.3 on iOS apply the member to installed apps; Safari 17 on macOS applies it to Dock apps (BCD html.manifest.display). Firefox 157 on desktop installs no web apps from the manifest, so the value has no consumer there. Modes outside the chain, window-controls-overlay and tabbed, are requested through display_override, never through display.

Member

• Type: string, one of fullscreen, standalone, minimal-ui, or browser.
• Default: browser. An absent member and an unrecognized value both resolve to browser; Chromium logs unknown 'display' value ignored. for the latter.
• Example value: "standalone".

What each value removes, from most to least:

• fullscreen takes the whole screen, including the OS status bar where the platform allows. On Android the app can still be left with the system back gesture.
• standalone opens a dedicated window with no address bar and no tab strip but keeps OS chrome such as the status bar and the window title bar.
• minimal-ui is standalone plus a minimal set of navigation controls; which controls appear is left to the browser (MDN lists back, forward, and reload as typical). Safari on iOS maps the value to standalone instead (BCD note for Safari iOS).
• browser opens a normal tab. Chromium treats it as a decision not to be an app: the installability check reports Manifest 'display' property must be one of 'standalone', 'fullscreen', or 'minimal-ui' and no install prompt is offered, unless a display_override entry supplies an app-like mode first.

The chain only runs downward. Request fullscreen and a platform without a fullscreen app window gives you standalone, then minimal-ui, then browser; you set the highest mode you want and nothing else. display governs in-scope pages only: a navigation outside scope brings back the address bar (Chrome) or an in-app banner (Safari iOS 16.4) whatever the mode.

Field notes

Chrome 155 on macOS 26 (English UI), DevTools > Application > Manifest: with "display": "browser" and no display_override, the Installability section reads Manifest 'display' property must be one of 'standalone', 'fullscreen', or 'minimal-ui' and the omnibox install icon does not appear. Changing the value to "standalone" and reloading clears the line and the icon returns.

Examples

The examples move from the manifest declaration to what the running page can learn about the mode it was given.

Requesting fullscreen for a game with a standalone fallback

A game asks for the whole screen. Where the platform refuses (desktop Chrome gives installed apps a window, not a kiosk), the chain lands on standalone and the game still runs without an address bar.

{
  "name": "Orbit",
  "start_url": "/play/",
  "scope": "/play/",
  "display": "fullscreen",
  "orientation": "landscape",
  "background_color": "#000000"
}

Pairing fullscreen with orientation matters on Android: the orientation lock applies only in fullscreen, standalone, and minimal-ui, so the same manifest in a browser tab is not locked.

Detecting the resolved mode at runtime

The browser does not expose the manifest’s requested value, but it does expose the mode it resolved, through the display-mode media feature (MDN, @media (display-mode)). Use it to hide a web-only header in an app window, and keep the header when the query matches nothing, which is the branch a browser tab takes.

const modes = ['window-controls-overlay', 'fullscreen', 'standalone', 'minimal-ui', 'browser'];

function resolvedDisplayMode() {
  const hit = modes.find((m) => matchMedia(`(display-mode: ${m})`).matches);
  if (hit) return hit;
  // Safari on iOS before 13 exposes the app window through navigator.standalone only.
  return navigator.standalone === true ? 'standalone' : 'browser';
}

document.documentElement.dataset.display = resolvedDisplayMode();

matchMedia reflects the window the page is in, so the same code reports browser for the site opened in a tab and standalone for the installed app, which is the test harness you need when checking a layout in both.

Keeping the web header out of the app window with CSS alone

When the only change is visual, skip the script and switch on the media feature directly.

.site-header {
  display: block;
}

@media (display-mode: standalone), (display-mode: fullscreen), (display-mode: minimal-ui) {
  .site-header {
    display: none;
  }
}

The rule leaves the header in place in a browser tab and in any engine that does not implement display-mode, which is the safe default for navigation.

See also

• display_override manifest member
• scope manifest member
• orientation manifest member
• Installability criteria: what makes a PWA installable
• Web Application Manifest: display member (w3.org)
• display-mode (developer.mozilla.org)

Specifications

Specification	Status
Web App Manifest: display	W3C
Web Application Manifest: display modes	W3C

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

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Android)	Yes	39	medium	source	—
Chrome (Desktop)	Yes	73	medium	source	—
Edge (Desktop)	Yes	79	medium	source	—
Safari (iOS)	Yes	11.3	medium	source	1
Safari (macOS)	Yes	17	medium	source	—
Firefox (Desktop)	No	—	medium	source	2
Samsung Internet	Yes	4.0	medium	source	—

1. standalone honored; minimal-ui falls back to standalone.
2. No desktop install path consuming display.

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

Source: spec · MDN · Last verified 2026-06-24 · Confidence: medium (computed from sources)