{{ summaryTitle }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ badge.label }}
Web app manifest generator inputs
Use the full product name users should recognize after installation.
Keep it near 12 characters so mobile launchers do not truncate it aggressively.
Describe the installed app in one concise sentence.
Use the deployed path that every installable page can load.
Prefer a stable absolute path such as / or /app/ instead of a campaign URL.
Use / for a whole-origin app, or a narrower path such as /dashboard/.
Keep this stable across releases, for example /launch-dashboard.
Standalone is the broad installable-app default; browser keeps normal browser chrome.
Use standard plus maskable when you have separate safe-zone icon artwork.
Use a cacheable project path without the size suffix.
Use an opaque hex color that matches the app chrome or brand accent.
Choose the first-load canvas color that fits your app shell.
Use a BCP 47-style tag such as en, en-US, ms-MY, or ja.
Leave Auto unless the app name needs a fixed LTR or RTL direction.
Use Any unless the app genuinely requires portrait, landscape, or fullscreen behavior.
Leave omitted unless you are targeting a platform-specific display feature.
One per line: New Report | /reports/new | Create a new report | New.
Use form_factor wide or narrow and include a descriptive label for accessibility.
{{ includeRelatedFalseBool ? 'Emit false' : 'Omit member' }}
Leave off while reviewing generated members; enable for compact deployment output.
{{ minifyBool ? 'Minified' : 'Pretty printed' }}

          

          
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 }}

          
Customize
Advanced
:

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.

Page manifest link flowing into JSON members for name, id, launch, scope, icons, colors, and install surfaces.

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.

Web app manifest member groups and review cues
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.

Generated review statuses and their meaning
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 Standalone for most PWA install drafts because it removes normal browser chrome without forcing fullscreen.
  • Use Standard + maskable icons only when both standard and safe-zone artwork will exist at the generated paths.
  • Keep Icon filename prefix as a path prefix, not a complete file name with a size suffix.
  • Choose opaque six-digit colors for Theme color and Background color so the checklist can read them cleanly.
  • Add Shortcuts only for high-frequency app tasks, with one line formatted as name, URL, description, and short name separated by pipes.
  • Add Screenshots when 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.

  1. Fill App name, Short name, and Description. The summary should move away from Manifest needs edits once a usable app label exists.
  2. Enter Manifest file path. The Install Markup tab should show a link rel="manifest" line that points to that path.
  3. Set Start URL, Scope, and App id. Open Install Checklist and check Start URL, Scope, Start inside scope, and Stable app id.
  4. Choose Display mode and, only when needed, open Advanced for Display override or Orientation. If Display mode says browser, expect a review note rather than an install-focused pass.
  5. Select Icon set, set Icon filename prefix, and review Asset Ledger. The generated sources should match the actual 192 by 192 and 512 by 512 files you plan to serve.
  6. Set Theme color, Background color, Language tag, and Text direction. If a color or language tag receives a review note, replace it with a six-digit hex color or a tag such as en, en-US, or ms-MY.
  7. Add optional Shortcuts and Screenshots rows 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.
  8. Use Manifest File as the deployment JSON after there are no Missing rows. Keep JSON for 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: