Manifest categories

Per MDN, the categories manifest member “lets you specify one or more classifications for your web application,” and “these categories help users discover your app in app stores.” The W3C Application Information registry, which defines the member, calls it “an array of strings that describes the application categories to which the web application belongs … meant as a hint to catalogs or stores listing web applications.”

Where it is supported

MDN states the position directly: “the categories manifest member is used by app stores when publishing and listing web apps, so browser compatibility is not applicable. While browsers may parse this member, it’s optional and doesn’t affect the app’s functionality or presentation.”

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

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Desktop)	— Not applicable	—	medium	source	1
Chrome (Android)	— Not applicable	—	medium	source	2
Edge (Desktop)	— Not applicable	—	medium	source	3
Samsung Internet	— Not applicable	—	medium	source	4
Firefox (Desktop)	— Not applicable	—	medium	source	5
Safari (iOS)	— Not applicable	—	medium	source	6

1. Not applicable: categories is app-store metadata read by install/distribution surfaces, never rendered or acted on by the browser engine itself.
2. Not applicable: categories is app-store metadata read by install/distribution surfaces, never rendered or acted on by the browser engine itself.
3. Not applicable: categories is app-store metadata read by install/distribution surfaces, never rendered or acted on by the browser engine itself.
4. Not applicable: categories is app-store metadata read by install/distribution surfaces, never rendered or acted on by the browser engine itself.
5. Not applicable: categories is app-store metadata read by install/distribution surfaces, never rendered or acted on by the browser engine itself.
6. Not applicable: categories is app-store metadata read by install/distribution surfaces, never rendered or acted on by the browser engine itself.

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

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

That is consistent with how the registry classifies the member. Its members “are classified as supplementary because they are not applied to a web application at runtime (i.e., they are purely advisory and don’t affect how a user agent presents an installed web application).”

How to use it

Per MDN, the value is “an array of comma-separated strings, where each string represents a category name,” and “the strings should be in lowercase.” The registry likewise says “manifest authors are encouraged to use lower-case.”

MDN’s example categorizes a meal-planning app:

{
  "name": "Meal Planner",
  "categories": ["food", "health", "lifestyle"]
}

For the vocabulary, MDN notes that “W3C maintains a list of standardized categories, which includes common values such as business, education, entertainment, finance, games, and productivity.” MDN also suggests when to use more than one: “if your app serves multiple purposes, specifying multiple relevant categories can help users discover your app across different sections of the app store.”

How to detect it at runtime

There is no runtime effect to detect. Per MDN, categories “is supplementary metadata that does not affect the app’s runtime behavior or how browsers present the app,” and its “values are used only in app stores and other distribution platforms and are not visible to users in the browser or installed app.”

What is worth checking is the value you ship, against a manifest object you already hold — in a build step, a test, or a review script. MDN describes the member as optional, so an absent value is a valid state the check has to handle rather than treat as an error:

// Normalize the declared categories from a manifest object you already have.
function declaredCategories(manifest) {
  const categories = manifest?.categories;
  if (!Array.isArray(categories) || categories.length === 0) {
    // Absent or empty: MDN documents the member as optional, so this is a valid
    // manifest. Report "none declared" and let the store classify the app.
    return [];
  }
  // MDN: the strings should be in lowercase.
  return categories.map((category) => String(category).toLowerCase());
}

Practical checklist

• Expect a best-effort match, not a guarantee. Per the registry, catalogs and stores “will make a best effort to find appropriate categories (or category) under which to list the web application,” but “like search engines and meta keywords, catalogs and stores are not required to honor this hint.”
• Plan for the store’s own taxonomy. Per MDN, “if categories is not specified or the specified values are not used, app stores will categorize your web app based on their own classification system.”
• Do not assume your exact strings are what users see. MDN’s note is that “the categories member is optional, and app stores may use different values when presenting your app.”
• Use lowercase. Both MDN and the registry say so explicitly.
• Do not use it to drive in-app behaviour: per MDN the member “doesn’t affect the app’s functionality or presentation,” and per the registry supplementary members “are not applied to a web application at runtime.”
• If you want a category to be discoverable in a store listing, remember that is the surface it reaches — MDN’s screenshots show the category appearing in an app store’s “CHART” field and as a dedicated “Category” field in the Information section.

Where to go next

• Web App Manifest: categories support — the compatibility entry for this member.
• Manifest description — another supplementary member the same registry defines.
• Manifest screenshots — a further store-listing member defined by the same registry.