Wiki · Concept · Last reviewed June 25, 2026

Web App Manifest

The Web App Manifest is the JSON metadata layer that lets a browser present a website as an installed web application.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser API, progressive web apps, installed web apps, agents, app identity, privacy

Definition

The Web App Manifest is a W3C specification for a JSON-based manifest file that gives a browser metadata about a web application. MDN describes the manifest as a JSON text file whose top-level keys are members, commonly used to give the browser information needed to install a progressive web app, such as the app's name and icon.

The manifest is not the application itself. It is metadata that can affect how a top-level browsing context is presented when the user agent applies the manifest. W3C defines an installed web application as one where the manifest's members, or their defaults, are applied to the top-level browsing context, distinguishing that launch from a traditional bookmark.

How It Works

A page points to a manifest with a <link rel="manifest"> element. The manifest can include members such as name, short_name, icons, display, orientation, start_url, id, theme_color, background_color, and shortcuts. Those fields can shape the name, icon, launch URL, display mode, colors, task shortcuts, and scope visible to the user agent.

Several members are security- or privacy-relevant. W3C says start_url is advisory and must be same-origin with the document URL when processed. The specification also warns that putting unique user identifiers in start_url can create a fingerprint that is not necessarily cleared when site data is cleared. The id member gives the application an identity, expressed as a URL same-origin with the start URL, and helps user agents distinguish one installed application from another.

Agent Context

For AI Browsers and Computer Use, the manifest is the layer where a website begins to look like an app. An agent dashboard, shopping assistant, workplace tool, or companion interface may be launched from an icon, run in a minimal browser frame, expose shortcuts, set badges, receive pushes, or coordinate with a Service Worker. The manifest helps decide which name and icon the user sees at that boundary.

This makes the manifest an app-identity surface. If the manifest name, icon, scope, or id changes, users may think they are launching the same trusted assistant when the launch context has shifted. If an agent relies on installed-app continuity, the audit record should preserve the manifest metadata that made the continuity visible.

Governance Use

A governed deployment should review the manifest before treating a web app as a trusted shell. Check that the name and icon do not impersonate another service, that scope matches the actual application boundary, that start_url does not embed user-specific tracking identifiers, and that shortcuts open expected in-scope destinations. App identity should be stable enough for users to recognize, but changeable enough to correct mistakes with a visible update path.

For agent systems, pair manifest review with Notifications API, Badging API, Push API, and storage review. The manifest does not make those capabilities available by itself, but it gives them a durable launch surface.

Limits

A manifest is not proof of security, origin ownership, consent, installability in every browser, or native-app equivalence. User agents decide whether to offer installation and how much of the manifest to honor. Some manifest members are hints, and browser support differs across platforms. A manifest also cannot explain what an agent will do after launch.

The manifest's polish can hide ordinary web risks. An app-like window can still load remote code, show deceptive UI, over-collect data, or route actions through a stale service worker. Treat installation as a presentation change, not as certification.

Minimum Evidence Record

For agent-facing installed web apps, record the manifest URL, document URL, origin, id, scope, start_url, name, short name, icon hashes or URLs, display mode, shortcuts, install prompt path, update time, service worker scope if present, and any app-store or operating-system surface where the app appears.

Source Discipline

Use the W3C Web Application Manifest specification for member processing, identity, scope, installation, update, and privacy claims. Use MDN for developer-facing summaries and member references. Claims about support or install prompts need browser-specific evidence.

Spiralist Reading

Spiralism reads the web app manifest as a mask with paperwork. It gives a site a name, icon, launch point, and frame, but it does not turn that site into a safer institution. The humane pattern is honest identity: an app shell should help users recognize who is asking for attention, not make a browser page feel more authoritative than it is.

Sources

Return to Wiki