manifest: handle_links support

manifest: handle_links — A WICG-proposed Web App Manifest member that lets an installed PWA suggest whether in-scope links should open inside the app instead of the browser, via the values preferred, not-preferred, and auto (the default).

Browser & ecosystem support

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

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Desktop)	No	—	medium	source	1

1. chromestatus.com tracks this feature's own implementation status as "On hold", with no shipping milestone.

Source data: /compatibility/manifest-handle-links.json · Global usage: 0 % (StatCounter 2026-05)

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

Per chromestatus.com, Chrome tracks this feature’s own implementation status as “On hold”, with no shipping milestone recorded.

How to use it

Declare the member in the manifest with one of the three values:

{
  "handle_links": "preferred"
}

Per the explainer, preferred means “the user agent should open in-scope links within the installed application”, not-preferred means it should not, and auto — the default when the member is omitted — means “the user agent should select the appropriate behavior for the platform”. The explainer describes these values as suggestions to the user agent, not directives it must follow.

How to detect it at runtime

The explainer does not define a JavaScript API for reading handle_links support back from the browser; it describes the member only as a manifest-level preference. The code below reads handle_links back from a manifest object the page already has (for example, one fetched and parsed with fetch('manifest.json').then(r => r.json())), with a fallback for when the member is omitted:

async function getHandleLinksPreference(manifest) {
  if (!('handle_links' in manifest)) {
    // Member omitted — the explainer names "auto" as the default.
    return 'auto';
  }
  return manifest.handle_links;
}

This reads the declared preference back; it cannot confirm whether the browser is honoring it, since the explainer does not expose that back to the page. For that reason, do not build link navigation that depends on handle_links taking effect — keep in-scope links as ordinary anchors and let handle_links, or its absence, apply itself.

Practical checklist

• Per chromestatus.com, this feature’s implementation status in Chrome is “On hold” with no shipping milestone — do not depend on preferred taking effect in production today.
• Per the explainer, the user agent “should” open in-scope links in the app for preferred and “should not” for not-preferred; only auto explicitly leaves the choice to platform-appropriate behavior.
• Per the explainer, handle_links operates on the app’s manifest scope; when the manifest also declares scope_extensions, that eligibility extends to the additional origins named there.
• auto is the default when handle_links is omitted from the manifest.

Where to go next

• manifest: scope support — defines the scope boundary that handle_links operates on.
• manifest: launch_handler support — a related manifest member controlling how an installed PWA is launched.

← Back to the Compatibility explorer.