W3C Publishes New Web App Manifest Working Draft: What PWA Developers Should Review
The World Wide Web Consortium (W3C) published an updated Working Draft of Web Application Manifest on October 26, 2026. The specification defines the JSON format websites use to describe an installable web application’s name, icons, launch URL and display preferences.
This is a standards draft, not a newly shipped browser feature or a finalized W3C Recommendation. Parts of the manifest format already work in browsers, but installation and display behavior vary between products and platforms. For teams building progressive web apps (PWAs), it is a useful moment to review the metadata users encounter when installing and opening an app.
What the draft means for an existing app
The document explicitly warns that the specification is not yet stable. Its publication does not mean every documented member is supported everywhere, or that an existing manifest needs an immediate rewrite.
Review the fields your app actually uses and test them on your supported devices. The practical questions are familiar: does the icon remain recognizable, does the name fit, and does launching the installed app take someone to a usable page?
What a web app manifest describes
A manifest is commonly delivered as a JSON file referenced from HTML:
<link rel="manifest" href="/manifest.webmanifest">
A simple illustrative manifest might look like this:
{
"name": "Recipe Notebook",
"short_name": "Recipes",
"start_url": "/app/",
"scope": "/app/",
"display": "standalone",
"icons": [
{ "src": "/icons/app-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icons/app-512.png", "sizes": "512x512", "type": "image/png" }
]
}
The name and short_name fields provide labels for app-related interfaces. icons lists image assets. start_url identifies the preferred launch location; scope defines the app’s navigation scope. display requests a presentation mode such as standalone, subject to browser support.
This example is not a universal installability checklist. A manifest also does not make an application work offline: that requires separate implementation and testing, often involving service workers and caching.
Give the icon a real review
An icon may be cropped or shown against different backgrounds. Check it at small sizes, then confirm that every icon URL returns an image with the declared format and dimensions. The two sizes in the example are illustrative; prepare the variants your supported platforms need.
For a prototype with a character-based identity, the Avatar Generator provides illustrative artwork. Its PNG download still needs checking and preparation for your intended app-icon uses. Our avatar announcement shows how to save and revisit a character while trying different backgrounds.
For the surrounding interface, Color Studio helps compare colors and text contrast. The Color Studio introduction explains how to turn a palette into usable shades and CSS variables.
Checks before shipping
- Fetch the manifest. Confirm that its URL returns valid JSON with a suitable content type, preferably
application/manifest+json. - Read the names and inspect the icons. Test small screens, cropping, padding and backgrounds.
- Launch directly. Open
start_urlwhile signed out as well as signed in. Check that the chosen scope covers the intended app paths. - Test presentation on real target platforms. Verify installation and display behavior in the browser and operating system combinations you support.
- Test offline behavior separately, if your app offers it.
The browser Network inspection guide can help verify manifest and icon responses. If an old icon keeps appearing, start by checking what the server actually returns; our HTTP caching tutorial explains how to inspect cache headers and validators. Installed-app updates may also follow browser-specific behavior, so a successful network fetch is only one part of that check.
Source: W3C Working Draft, October 26, 2026. The current specification page tracks subsequent published revisions.