Manifest: description support

Web App Manifest: description — per MDN, the description manifest member “is used to explain the core features or functionality of your web application,” and that text “helps users understand your app’s purpose when viewing it in an app store.” MDN notes the member is optional, and app stores may not use the text when presenting the app.

Browser & ecosystem support

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

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Desktop)	Yes	88	high	source	—
Chrome (Android)	Yes	88	high	source	1
Edge (Desktop)	Yes	88	high	source	2
Firefox (Desktop)	No	—	high	source	3
Firefox (Android)	No	—	high	source	4
Safari (macOS)	No	—	high	source	5
Safari (iOS)	No	—	high	source	67
Samsung Internet	Yes	15.0	high	source	8
WebView (Android)	Yes	88	high	source	9

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. The property parses, but has no effect.
5. No Safari support is recorded in browser-compat-data.
6. No Safari on iOS support is recorded in browser-compat-data.
7. Derived by browser-compat-data mirroring from Safari.
8. Derived by browser-compat-data mirroring from Chrome Android.
9. Derived by browser-compat-data mirroring from Chrome Android.

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

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

How to use it

{
  "name": "My App",
  "description": "Track your habits and build streaks, even offline."
}

How to detect it at runtime

MDN states that description “does not affect the app’s runtime behavior or how browsers present the app,” and per MDN’s own compat data, Firefox for Android “parses, but has no effect.” Neither source describes a way for a script to query whether the current browser implements or acts on this member — fetching and parsing the page’s own manifest only confirms what the site declared, not whether the browser will do anything with it:

async function manifestDeclaresDescription() {
  if (typeof document === 'undefined') {
    // Fallback: no manifest link element available in this context.
    return false;
  }
  const link = document.querySelector('link[rel="manifest"]');
  if (!link) return false;
  const manifest = await fetch(link.href).then((r) => r.json());
  return typeof manifest.description === 'string' && manifest.description.length > 0;
}

Use this only as a deployment check (did the manifest ship with a non-empty description?), not as a support check. Because the browser can’t confirm whether the text will actually be surfaced, provide the same copy through a channel you control — an in-page “About this app” section or your own app-store listing metadata — instead of relying on the manifest member alone.

Practical checklist

• Per MDN’s browser-compat-data, Firefox does not support description at all — do not rely on it being surfaced there.
• MDN’s data notes that on Firefox for Android specifically, the property parses without error but has no effect, so validation alone won’t tell you it’s being ignored.
• Safari does not implement description, per the same browser-compat-data — see the table above for the full per-browser picture before depending on this member for any app-store text you don’t control.
• MDN notes description is optional and that app stores may not use the text even where the member itself parses.

Where to go next

• Web App Manifest: related_applications / prefer_related_applications support

← Back to the Compatibility explorer.