Summary

  • The W3C's December 2013 first public manifest draft put a website's name, icons and preferred launch address in one linked JSON document.
  • The October 2026 W3C Working Draft adds a more developed vocabulary for name, icon, start URL, scope, display preference and stable app identity; the user agent applies that metadata to its own interface.

Imagine a website arriving at the front desk of a large apartment building. It would like its own little square in the lobby directory. It has a name, a picture for the bell and instructions for which door visitors should use. It cannot pick the lock, and it cannot insist that every resident add it to a phone. It can, however, stop handing the concierge three contradictory scraps of paper.

A browser tab already had a title and a favicon. A site aspiring to a place in a device's app menu needed a more coherent introduction. Which name should fit beneath an icon? Which graphic belongs there? When someone taps it, which URL is the front door? If a launched page moves elsewhere, where does the app-like experience end? These are mundane questions. Mundane questions become architecture when every site and browser answers them differently.

The W3C's first public draft of 17 December 2013 was called Manifest for web apps and bookmarks. It proposed a central JSON document for web-application metadata and a link rel="manifest" in HTML to associate the page with it. The abstract listed a name, icons and a preferred launch URL. Its examples imagined a web app added to a home screen, with an icon that could sit beside other software. A website had begun to write its own calling card.

The early calling card had a vocabulary of its own. Its example used name, url, mode: standalone and icons. Those fields reveal the ambition of the first draft, even as the exact format evolved. The site wanted to be recognizable outside the tab and to open at a chosen starting point. A browser needed a machine-readable statement to use when it offered such an experience. The draft was a proposal, and its value as a historical document lies in how plainly it framed the request.

The W3C's 16 October 2026 Working Draft shows how the card grew up. A JSON manifest can carry name and short_name, icon resources, a preferred start_url, a scope, a display mode and other presentation details. It can also carry an id that identifies the web app apart from the particular page used as its launch URL. The site's public face and its front door have separate fields. A publisher can maintain each deliberately.

The name matters because interfaces are cramped. An app list may have space for the shorter label, while a fuller name can appear elsewhere. Icons matter because the small square on a phone is a promise of recognition; a fuzzy or unrelated mark makes that promise difficult to keep. The manifest lets the publisher offer the relevant resources in one place. A browser applies them according to its own capabilities and presentation.

start_url is the site's preferred place to begin when the user launches the web app. The 2026 draft expressly treats that preference as advice to the user agent. The browser may choose another behavior or let the reader change the start address. This is the front-desk arrangement in miniature: the tenant supplies directions, the building runs the entrance. The distinction also prevents a single URL from carrying the whole burden of identity. The newer id member gives the app a stable identifier even when its preferred entry path changes.

scope draws a map around the app's navigational home. The draft uses it to describe which URLs belong to the application's context. When navigation travels outside that map, the user agent can present the destination differently. The map is a useful piece of interface information: the reader can tell when the journey has left the place they launched. It also forces a publisher to think about where the app actually begins and ends, rather than treating a domain as one enormous apartment.

display records a preferred mode of presentation. The draft describes choices such as standalone and fullscreen, subject to user-agent handling. The manifest expresses how the publisher would like the app to appear after launch; it is the nameplate and floor plan handed to the concierge. The reader sees whatever experience their browser and device make available. The same JSON cannot decree a universal installation button across every operating system.

The W3C publication history stretches from that first public draft in December 2013 to the October 2026 Working Draft. The timeline is a history of documents, not a scoreboard of browsers. The more interesting continuity is the small request at its center: let a website state its identity and preferred entrance once, in a place software can find.

A page linked to a manifest still has to earn its place on a reader's device. The manifest gives the browser a tidy file to consult when it offers an app-like surface. The resident decides whether to make room on the home screen. One might say the site has brought all its papers. At least nobody has to guess which doorbell belongs to it.