# display manifest member

> The display member picks how much browser UI an installed web app keeps: fullscreen, standalone, minimal-ui, or browser, on a fixed fallback chain.

`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.

:::observed
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.

```json
{
  "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.

```js
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.

```css
.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](/reference/manifest/display-override/)
- [scope manifest member](/reference/manifest/scope/)
- [orientation manifest member](/reference/manifest/orientation/)
- [Installability criteria: what makes a PWA installable](/reference/installation/installability-criteria/)
- [Web Application Manifest: display member](https://www.w3.org/TR/appmanifest/#display-member) (w3.org)
- [display-mode](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/display-mode) (developer.mozilla.org)