Web App Manifest Generator
Generate web app manifest JSON from app names, launch URLs, scope, icons, colors, display mode, shortcuts, screenshots, and install review checks.{{ summaryTitle }}
- {{ row.detail }} Next: {{ row.nextStep }}
| Status | Check | Detail | Next step | Copy |
|---|---|---|---|---|
| {{ row.status }} | {{ row.check }} | {{ row.detail }} | {{ row.nextStep }} |
| Type | Purpose | Source | Sizes | Notes | Copy |
|---|---|---|---|---|---|
| {{ row.type }} | {{ row.purpose }} | {{ row.source }} | {{ row.sizes }} | {{ row.notes }} |
Introduction:
A web app manifest is a JSON document that tells browsers how a web application should be named, launched, displayed, and represented when a user installs it. It connects ordinary pages to app-like surfaces such as home-screen icons, launcher entries, install prompts, and splash screens. The manifest does not make an application reliable by itself, but it gives the browser the metadata needed to present the application consistently after installation.
Manifest work matters most when a site is ready to behave like a Progressive Web App, or PWA. A good manifest answers practical launch questions: what name should users see, where should the app open, which URLs belong inside the app, which icon artwork should be used, and what color should appear around the first launch surface. Small mistakes can be visible immediately, such as a truncated launcher label, a missing icon, or an installed window that opens outside the expected workflow.
The manifest is also a review document. A valid JSON file can still point to icons that do not exist, use a start URL outside the intended app area, or choose a display mode that does not match install expectations. Treat the finished manifest as a deployment draft that still needs real browser testing, asset checks, HTTPS hosting, and the application code that makes the installed experience useful.
Technical Details:
Web app manifests are fetched through an HTML manifest link and parsed as JSON. The top-level object can include identity members, launch members, display preferences, icon resources, shortcut items, and supplementary listing information. User agents may ignore unsupported or invalid members, so a manifest should be both syntactically valid and easy to audit against the surfaces it is meant to support.
Identity and launch settings are the highest-risk fields because they can change how an installed app is recognized. The id member gives the installed app a durable identity, while start_url describes the normal launch target. The scope member defines the navigation area where the installed app behavior applies. A start URL outside scope is a real review problem because the app may launch into a page that no longer behaves like part of the installed application.
Rule Core
The manifest draft follows a member-by-member rule set. Required-looking items are not all required by the specification, but practical install surfaces usually need a recognizable name, a launch URL, an app-like display mode, and usable icons.
| Member group | Members | What changes | Review cue |
|---|---|---|---|
| Identity | name, short_name, description, id |
Install prompt label, launcher label, accessible app description, and stable app identity. | Keep the full name recognizable and the short name near 12 characters. |
| Launch boundary | start_url, scope |
The first page opened from the installed icon and the URL area treated as the app. | start_url should resolve and stay inside scope. |
| Window behavior | display, display_override, orientation |
Preferred browser chrome, experimental display preferences, and launch orientation. | standalone, minimal-ui, or fullscreen fits common install audits better than browser. |
| Visual startup | icons, theme_color, background_color |
Launcher artwork, maskable icon candidates, browser UI tint, and first-paint background. | Use real 192 by 192 and 512 by 512 PNG files and opaque six-digit hex colors. |
| Task access | shortcuts |
Optional app-icon context menu entries for high-frequency tasks. | Each shortcut needs a name and URL, and its URL should stay inside scope. |
| Listing context | screenshots |
Optional install or catalog imagery for wide and narrow form factors. | Each screenshot should include a size and a useful label for accessibility. |
Icon purpose deserves separate attention. Standard icons with purpose: any are used where the full square can be shown. Maskable icons allow platforms to crop artwork into adaptive shapes, so the important mark needs enough safe area around it. Listing both standard and maskable entries is useful only when the actual image files match those roles.
| Status | Meaning | Typical trigger | Next check |
|---|---|---|---|
Pass |
The entered value meets the generator's static review rule. | Name present, colors match #RRGGBB, or icon sizes include the normal pair. |
Verify the deployed resource still exists and loads in a browser manifest panel. |
Review |
The manifest can still be generated, but the choice may cause install or presentation trouble. | Long short name, browser display mode, invalid-looking color, or start URL outside scope. |
Change the field or record why the exception is intentional. |
Missing |
A blocker prevents a useful manifest draft from being copied or downloaded. | No app name or short name, no parseable start URL, or no required icon size pair. | Fix the missing value before using the manifest output. |
Info |
An optional area has no generated rows. | No shortcuts or screenshots entered. | Add rows only when those surfaces matter for the app. |
The generated link should point to a path ending in .webmanifest or .json. The official media type is application/manifest+json, and browsers also commonly accept JSON content types. File extension and content type do not replace semantic checks: the linked resource must be reachable, parseable, and consistent with the app pages that reference it.
Everyday Use & Decision Guide:
Start with the public identity fields. Enter App name as the full label users should recognize, then keep Short name compact enough for a phone launcher. Use Description for a one-sentence install prompt or catalog summary, not for release notes or marketing copy that will age quickly.
Set Manifest file path to the path your pages will reference, then set Start URL, Scope, and App id as a group. A common first pass is /manifest.webmanifest, /, /, and a stable app id such as /launch-dashboard. For an app hosted under a folder, keep all three path decisions under the same base path so the installed icon does not open outside the app area.
- Use
Standalonefor most PWA install drafts because it removes normal browser chrome without forcing fullscreen. - Use
Standard + maskable iconsonly when both standard and safe-zone artwork will exist at the generated paths. - Keep
Icon filename prefixas a path prefix, not a complete file name with a size suffix. - Choose opaque six-digit colors for
Theme colorandBackground colorso the checklist can read them cleanly. - Add
Shortcutsonly for high-frequency app tasks, with one line formatted as name, URL, description, and short name separated by pipes. - Add
Screenshotswhen install listings need richer context, and include a descriptive label for each row.
The main wrong assumption is that a generated manifest makes a site installable. The output covers manifest members, install markup, checklist rows, and asset references. It does not create icon image files, register a service worker, prove HTTPS deployment, or confirm that the app works after launch. Use the checklist as a preflight review, then test the deployed page in browser developer tools.
When some details are still rough, generate a draft anyway and read the Review before publishing alert. A review row for a long short name or missing maskable icon is often enough to guide the next design or asset task before a production handoff.
Step-by-Step Guide:
Build the manifest from identity to launch behavior, then use the checklist and asset ledger before copying the final JSON.
- Fill
App name,Short name, andDescription. The summary should move away fromManifest needs editsonce a usable app label exists. - Enter
Manifest file path. TheInstall Markuptab should show alink rel="manifest"line that points to that path. - Set
Start URL,Scope, andApp id. OpenInstall Checklistand checkStart URL,Scope,Start inside scope, andStable app id. - Choose
Display modeand, only when needed, openAdvancedforDisplay overrideorOrientation. IfDisplay modesaysbrowser, expect a review note rather than an install-focused pass. - Select
Icon set, setIcon filename prefix, and reviewAsset Ledger. The generated sources should match the actual 192 by 192 and 512 by 512 files you plan to serve. - Set
Theme color,Background color,Language tag, andText direction. If a color or language tag receives a review note, replace it with a six-digit hex color or a tag such asen,en-US, orms-MY. - Add optional
ShortcutsandScreenshotsrows only when they describe real app tasks or real listing images. If a shortcut falls outside scope or a screenshot has no label, fix the row before sharing the manifest. - Use
Manifest Fileas the deployment JSON after there are noMissingrows. KeepJSONfor the broader review payload when someone needs the checklist and asset rows alongside the manifest.
A finished pass should leave a copyable manifest, matching install markup, and a checklist whose remaining review notes are either fixed or intentionally accepted.
Interpreting Results:
The summary headline is the first gate. Manifest needs edits means one or more blockers remain and manifest copy is disabled. Manifest ready with notes means the JSON can be used for review, but at least one row still deserves a human decision. Installable manifest ready means the static checks found no blocker or review row in the current inputs.
Manifest File is the manifest text to serve from the chosen path. Install Markup is the page-head snippet that points browsers to that path and mirrors the theme color when one is provided. Install Checklist explains whether each major member passes, needs review, is missing, or is optional. Asset Ledger lists the icon and screenshot paths the manifest expects to exist.
Do not treat a clean checklist as proof that installation will succeed. The review cannot fetch the future manifest path, inspect real icon pixels, confirm service worker behavior, or know whether browser-specific install criteria are satisfied. Test the deployed page in a fresh browser profile, open the manifest panel, and verify that every referenced icon and screenshot returns the expected file.
If results look surprising, start with path relationships. A start URL that is outside scope, a prefix that produces nonexistent icon paths, or a manifest link that lacks a recognizable extension can make a valid JSON file behave poorly after deployment.
Worked Examples:
Launch Dashboard Draft
A team enters Launch Readiness Dashboard for App name, Launch for Short name, keeps Start URL and Scope at /, and uses Standard + maskable icons with /icons/launch-dashboard. Manifest File should include four icon entries, Install Checklist should pass the name, launch, scope, display, icon, and color checks, and Asset Ledger should list standard and maskable 192 by 192 and 512 by 512 PNG paths.
Folder App With A Scope Mistake
A reporting app lives under /dashboard/, but Start URL is set to /reports/new while Scope is /dashboard/. The manifest can still be generated, yet Start inside scope should move to Review. The correction is to move the launch URL under /dashboard/ or widen scope only if the larger URL area truly belongs to the installed app.
Launcher Label Too Long
A product name such as Enterprise Launch Control Center works as App name, but using the same value as Short name should trigger a Launcher label review because it exceeds the 12-character guide. Changing Short name to Launch keeps the full install prompt recognizable while giving compact launch surfaces a cleaner label.
Troubleshooting A Disabled Copy Button
If both App name and Short name are blank, the summary should say Manifest needs edits, Install Checklist should mark App name as Missing, and Copy manifest remains disabled. Entering either a full name or a short name clears that blocker so the remaining review notes can be handled normally.
FAQ:
Does the generator create the icon files?
No. It writes manifest icon entries and lists the expected paths in Asset Ledger. You still need to create and deploy the real PNG files at those paths.
Why is Copy manifest disabled?
Copy is disabled when Install Checklist has a Missing row, such as no app name or short name. Fix the missing value, then copy the manifest after the blocker count reaches zero.
Does this add a service worker?
No. The output is manifest JSON, install markup, checklist rows, asset rows, and a structured review payload. A PWA still needs application code and any service worker behavior handled elsewhere.
Why does a shortcut URL need to stay inside scope?
A shortcut is meant to open a task inside the installed app. If its URL is outside Scope, the checklist marks Shortcut scope for review so the path can be moved or the scope decision can be reconsidered.
Is manifest data uploaded while I edit it?
Manifest text, install markup, checklist rows, and asset rows are generated in the browser session. Treat copied output, downloaded files, screenshots, and shared URLs as deployment information because they can reveal internal paths and product names.
Glossary:
- Web app manifest
- A JSON document that gives browsers app identity, launch, icon, color, and display metadata.
- PWA
- A Progressive Web App, meaning a web application intended to provide app-like install and launch behavior.
- Start URL
- The URL opened when the installed app launches from an icon or similar surface.
- Scope
- The URL boundary where manifest behavior applies to the installed app.
- App id
- A stable identifier that helps keep the installed app identity from changing when launch paths change.
- Display mode
- The preferred window presentation, such as browser, minimal UI, standalone, or fullscreen.
- Maskable icon
- An icon resource prepared with enough safe area for platforms that crop app artwork into adaptive shapes.
- Service worker
- A separate browser feature often used by PWAs for caching and background behavior, not generated by this manifest draft.
References:
- Web Application Manifest, W3C, Working Draft 01 May 2026.
- Web application manifest, MDN Web Docs, last modified August 8, 2025.
- Web App Manifest - Application Information, W3C.
- Add a web app manifest, web.dev, last updated 2024-09-18.
- Web app manifest, web.dev, last updated 2024-12-09.