Web App Manifest Generator

App name:

Use the full product name users should recognize after installation.

Short name:

Keep it near 12 characters so mobile launchers do not truncate it aggressively.

Description:

Describe the installed app in one concise sentence.

Manifest file path:

Use the deployed path that every installable page can load.

Start URL:

Prefer a stable absolute path such as / or /app/ instead of a campaign URL.

Scope:

Use / for a whole-origin app, or a narrower path such as /dashboard/.

App id:

Keep this stable across releases, for example /launch-dashboard.

Display mode:

Standalone is the broad installable-app default; browser keeps normal browser chrome.

Icon set:

Use standard plus maskable when you have separate safe-zone icon artwork.

Icon filename prefix:

Use a cacheable project path without the size suffix.

Theme color:

Use an opaque hex color that matches the app chrome or brand accent.

Background color:

Choose the first-load canvas color that fits your app shell.

Review before publishing

{{ row.detail }} Next: {{ row.nextStep }}

Language tag:

Use a BCP 47-style tag such as en, en-US, ms-MY, or ja.

Text direction:

Leave Auto unless the app name needs a fixed LTR or RTL direction.

Orientation:

Use Any unless the app genuinely requires portrait, landscape, or fullscreen behavior.

Display override:

Leave omitted unless you are targeting a platform-specific display feature.

Shortcuts:

One per line: New Report | /reports/new | Create a new report | New.

Screenshots:

Use form_factor wide or narrow and include a descriptive label for accessibility.

Installability guard:

Minify manifest:

Leave off while reviewing generated members; enable for compact deployment output.

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

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Installable web apps rely on a small JSON document to tell browsers how the app should appear after a user adds it to a device. The web app manifest carries the public-facing identity: the full name, compact launcher label, icon candidates, launch URL, display preference, language, direction, and startup colors. Without that metadata, a website may still load normally, but the installed experience can look unfinished or fail a browser's install checks.

Manifest work is not only a syntax task. It connects brand naming, URL routing, icon production, browser support, store-style listing images, and release testing. A manifest can be valid JSON while still causing a clipped launcher label, a start URL that opens the wrong page, an app identity that changes between releases, or an adaptive icon that gets cropped around the wrong safe area.

Common web app manifest concerns and mistakes
Concern	What It Decides	Common Mistake
Identity	The full name, compact launcher label, language, direction, and durable installed app ID.	Changing the ID or relying on a campaign-heavy launch URL for identity.
Launch boundary	The first page opened from the installed icon, plus the URL area considered part of the app.	Setting a start URL that falls outside the intended scope.
Presentation	Whether the app prefers a browser tab, minimal UI, standalone window, or fullscreen launch.	Choosing browser display mode when the target is app-like installation.
Assets	The icon and screenshot resources browsers may use for launchers, splash screens, and richer install prompts.	Listing paths before the real deployed images exist at the required sizes.

A page manifest link pointing to manifest JSON, then to installed app launch surfaces.

A manifest is one ingredient in Progressive Web App readiness, not the whole recipe. It does not create image files, add a service worker, make an insecure origin installable, or guarantee that every browser will honor every member. Chromium-based install checks commonly expect a name or short name, 192 by 192 and 512 by 512 icons, a start URL, a display choice, and no preference for a related native app, but other platform behavior can still differ.

Launch paths and app IDs deserve privacy and stability care. A start URL can remain tied to an installed app, so it should not contain account IDs, user tokens, or one-time campaign parameters. Clean, durable paths make future releases easier to test and reduce the chance that an update looks like a separate installed app.

How to Use This Tool:

Draft the manifest from identity outward, then use the generated checklist to decide what needs correction before deployment.

Enter App name, Short name, and Description. The summary should move away from Manifest needs edits once either the full name or compact name is present.
Set Manifest file path. The Install Markup output should show a link rel="manifest" line for that path, plus a theme-color meta tag when a theme color is available.
Choose Start URL, Scope, and App id together. If Start inside scope moves to Review, place the launch path under the scope or widen scope only when the larger URL area belongs to the app.
Select Display mode and review any Display mode note. Standalone, Minimal UI, and Fullscreen match common install-focused checks; Browser is valid JSON but may not fit app-like installation goals.
Choose Icon set and Icon filename prefix. Confirm that Asset Ledger lists the 192 by 192 and 512 by 512 icon paths you will actually deploy, including maskable variants when selected.
Use the Advanced fields for real release needs: Language tag, Text direction, Orientation, Display override, Shortcuts, Screenshots, and the related-app guard. Leave optional members out when they would not change the installed experience.
Read Install Checklist before copying Manifest File. Fix Missing rows first, then decide whether each Review row is acceptable for the release.

When Copy manifest is disabled, the checklist has at least one blocker. The usual recovery path is to add an app name or short name, correct the start URL, or choose an icon option that emits the required sizes.

Interpreting Results:

The summary is a release-readiness signal for the current draft, not proof that the deployed app is installable. Manifest needs edits means at least one blocker remains. Manifest ready with notes means the JSON can be reviewed, but the checklist found choices worth checking. Installable manifest ready means the static rules found no blocker or review note in the entered values.

Use Manifest File as the JSON to publish, Install Markup as the page-head snippet, Install Checklist as the review trail, and Asset Ledger as the list of external files the manifest expects. The JSON output combines those results for review or handoff.

Web app manifest result statuses
Status	Meaning	Typical Trigger	Next Check
`Pass`	The current value matches the tool's static rule.	Name present, start URL parsed, icon sizes present, or colors shaped like `#RRGGBB`.	Test the deployed manifest in browser developer tools.
`Review`	The manifest can still be generated, but the choice may affect installation or presentation.	Long short name, browser display mode, start URL outside scope, or invalid-looking color.	Change the field or document why the exception is intentional.
`Missing`	A blocker prevents a useful manifest draft from being copied or downloaded.	No app name or short name, an unparseable start URL, or no required icon-size pair.	Fix the missing value before using the manifest output.
`Info`	An optional area has no generated entries.	No shortcuts or screenshots were entered.	Add entries only when they represent real app tasks or listing images.

Do not treat a clean checklist as a browser acceptance test. It cannot fetch future asset paths, inspect icon pixels, check HTTPS, confirm service worker behavior, or prove that every target platform will offer installation. Publish to a test environment and inspect the parsed manifest before release.

Technical Details:

The Web Application Manifest specification defines a JSON-based metadata file for a web application. The core members describe identity, launch behavior, icons, display preference, orientation, colors, shortcuts, screenshots, and related application preferences. Most members are optional in the specification, while real install prompts often depend on a smaller practical subset plus deployment facts that the manifest text alone cannot prove.

Launch identity has three connected parts. start_url names the preferred page to load when the installed app starts, id gives the app a stable identity that can survive future launch-path changes, and scope sets the navigation boundary where the installed app experience applies. When these values disagree, the manifest may still parse, but users can land outside the intended app area or future releases can be treated as a different installed app.

Rule Core:

Manifest member groups and release review rules
Member Group	Members	What Changes	Review Rule
Identity	`name`, `short_name`, `description`, `id`	Install prompt label, compact launcher label, descriptive context, and installed app identity.	At least one name must be present; keep the compact name near 12 characters and keep `id` stable.
Launch boundary	`start_url`, `scope`	The first loaded page and the URL range treated as part of the app.	`start_url` should parse successfully and resolve inside `scope`.
Window behavior	`display`, `display_override`, `orientation`	Preferred browser chrome, first-choice display behavior, and launch orientation.	Use `display_override` only when a specific supported platform behavior is being targeted.
Visual startup	`icons`, `theme_color`, `background_color`	Launcher artwork, splash-screen ingredients, browser UI tint, and first-paint background color.	Include 192 by 192 and 512 by 512 PNG entries, and use opaque six-digit hex colors.
Task entry points	`shortcuts`	Optional app-icon menu entries for frequent tasks.	Each shortcut needs a name and URL, and shortcut URLs should stay inside scope.
Listing context	`screenshots`	Optional install or catalog imagery for wide and narrow form factors.	Each screenshot should include a source, size, form factor when known, and useful label.
Related app preference	`prefer_related_applications`	Whether the browser should prefer a related native app over the web app.	Leave it false or absent unless a native app handoff is an intentional product decision.

Summary Count Rule:

The readiness summary is driven by checklist status counts rather than a separate manifest standard.

\begin{array}{lcl} blocking_count & = & count (Install Checklist entries marked Missing) \\ review_count & = & count (Install Checklist entries marked Review) \\ icon_asset_count & = & count (Icon entries in Asset Ledger) \end{array}

Maskable icons need more than a different manifest entry. Adaptive platforms may crop an icon into circles, rounded squares, or other shapes, so the important artwork should sit inside the safe area with enough padding. Listing both standard and maskable icons is useful only when the actual files are prepared for those roles.

The manifest file is commonly linked with rel="manifest". The official extension is .webmanifest, and the preferred media type is application/manifest+json, though many deployments still use JSON-compatible filenames. Extension and content type do not replace release testing: the linked resource must load, parse, reference reachable files, and match the pages that advertise it.

Limitations and Privacy Notes:

Generated manifest text, markup, checklist entries, and asset rows are produced in the browser while you edit. That reduces generation-time data exposure, but copied output, downloaded files, shared page URLs, and deployed manifests can reveal internal product names, app paths, or release structure.

The checks do not request the future manifest path, icon files, screenshots, service worker, or HTTPS certificate.
Browser support varies for newer manifest members; unsupported members may be ignored while the manifest remains valid JSON.
A start URL should not contain user-specific identifiers because installed app launch data can persist outside normal page history.

Worked Examples:

Launch Dashboard:

A team enters Launch Readiness Dashboard as App name, Launch as Short name, keeps Start URL and Scope at /, and selects Standard + maskable icons with /icons/launch-dashboard. Manifest File should include identity, launch, color, display, and four icon entries. Asset Ledger should list standard and maskable 192 by 192 and 512 by 512 PNG paths.

Scoped Reporting App:

A reporting app belongs under /dashboard/, but Start URL is set to /reports/new while Scope is /dashboard/. Start inside scope should appear as Review. Moving the launch URL to /dashboard/reports/new keeps the installed app inside the intended URL boundary.

Launcher Label Review:

A full product name such as Enterprise Launch Control Center is reasonable for App name, but using it as Short name should trigger a Launcher label review because it is longer than the compact guide. Changing Short name to Launch keeps the full name available while giving small launch surfaces a cleaner label.

Disabled Copy Button:

If both App name and Short name are blank, the summary should show Manifest needs edits, Install Checklist should mark App name as Missing, and Copy manifest remains unavailable. Entering either name clears that blocker.

After any draft, load the deployed page in browser developer tools and verify the parsed manifest, icons, screenshots, launch path, and shortcuts.

FAQ:

Does the manifest create the icon files?

No. Manifest File lists icon paths, and Asset Ledger shows what those paths should be. You still need to create and deploy the real image files.

Why is Copy manifest unavailable?

Copy manifest is unavailable when Install Checklist has a Missing entry. Add an app name or short name first, then check whether any other blocker remains.

Does a valid manifest make a PWA installable?

Not by itself. A manifest supplies app metadata, but installation can also depend on HTTPS, browser rules, service worker behavior, engagement rules, and whether referenced assets load.

Why should shortcut URLs stay inside scope?

A shortcut should open a task inside the installed app. If a shortcut URL is outside Scope, Shortcut scope moves to Review so the path or scope can be corrected.

Should start URLs include tracking or user IDs?

Avoid that. A start URL can stay associated with an installed app, so use stable app paths instead of account IDs, user tokens, or one-off campaign parameters.

Glossary:

Web app manifest: A JSON document that provides app identity, launch, icon, color, and display metadata to browsers.
PWA: A Progressive Web App, meaning a web application intended to support app-like installation and launch behavior.
Start URL: The URL a browser should open when the installed app launches.
Scope: The URL boundary where the installed app experience applies.
App ID: A stable identifier used to recognize the installed app across manifest updates.
Display mode: The preferred window presentation, such as browser, minimal UI, standalone, or fullscreen.
Maskable icon: An icon prepared with safe-area padding so adaptive platforms can crop it into different shapes.
Service worker: A separate browser feature often used by PWAs for caching and offline behavior; it is not created by a manifest.

References:

Web Application Manifest, W3C Working Draft, 07 May 2026.
Web application manifest, MDN Web Docs.
Making PWAs installable, MDN Web Docs.
Web app manifest, web.dev.
Add a web app manifest, web.dev.