Web App Manifest Generator

Checks{{ computation.ok ? values.ready_count + '/' + values.check_count : '—' }} Review{{ computation.ok ? values.review_count : '—' }} Icons{{ computation.ok ? values.icon_count : '—' }}

App name:

Use the product name people should recognize after installation.

Short name:

Keep it concise; this tool flags labels longer than 12 characters for device review.

Description:

Describe the installed app in one concise sentence.

Manifest file path:

The .webmanifest extension and application/manifest+json media type are recommended, not mandatory.

Start URL:

Use a durable same-origin path without account IDs, tokens, or campaign parameters.

Navigation scope:

Use / for the whole origin or a narrower application path ending in /.

Stable app ID:

Keep this value stable across releases.

Display mode:

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

Icon profile:

Use separate maskable artwork with safe-zone padding when adaptive cropping matters.

Icon filename prefix:

Enter a path without a size suffix or image extension.

Theme color:

Use an opaque six-digit hex color for predictable review output.

Background color:

Match the first-load canvas of the application.

Language tag:

Blank omits the member; examples include en, en-US, and zh-Hans-CN.

Text direction:

Blank is neutral; choose a value only when the manifest text needs an explicit direction.

Orientation:

Blank leaves orientation to the user agent and device.

Display override:

Blank is neutral; explicit overrides fall back to the primary display mode.

Shortcuts:

One per line: Name | URL | Description | Short name. Blank emits no shortcuts.

Screenshots:

One per line: src | sizes | wide or narrow | label. Blank emits no screenshots.

Related-app preference:

The neutral default omits the member.

{{ params.include_related_false ? 'Emit false' : 'Omit member' }}

Manifest formatting:

The neutral default keeps the generated file readable.

{{ values.manifest_text }}

{{ values.install_markup }}

Status	Check	Evidence	Next action	Copy
{{ row.status }}	{{ row.check }}	{{ row.evidence }}	{{ row.next_action }}

Type	Purpose	Source	Sizes	Notes	Copy
{{ row.type }}	{{ row.purpose }}	{{ row.source }}	{{ row.sizes }}	{{ row.notes }}

Installing a website changes the relationship between its pages and the browser. The site gains a launcher entry, a name and icon outside the browser tab, a preferred opening route, and a window style that may hide some browser controls. A web application manifest supplies the JSON metadata for those choices.

The manifest does not contain the application itself. It points to public resources and tells a supporting browser how the installed experience should begin. A valid file can still describe a poor release if its icon paths are broken, its compact name is unreadable on a launcher, or its start URL opens beyond the intended application boundary.

Identity: The full name, short name, stable ID, language, and text direction that distinguish one installed application from another.
Launch route: The start_url opened from the installed icon. Durable routes are safer than URLs containing user IDs, access tokens, or campaign parameters.
Navigation scope: The same-origin path boundary that defines which navigations remain within the application experience.
Presentation hints: Display mode, orientation, colors, icons, shortcuts, and screenshots that a browser may use when it supports them.

Identity and routing deserve the most care. A stable id helps an installed application remain the same application when its launch route changes. The start URL should sit inside the declared scope, while shortcut URLs should lead to real tasks inside that boundary. Widening scope just to silence a warning can unintentionally make unrelated pages feel like part of the installed app.

Support varies by browser and operating system. Manifest members are preferences that user agents process according to their own capabilities and policies. A browser may ignore an unfamiliar display override, crop artwork for a device-specific shape, or apply additional install criteria that a static manifest review cannot test.

A manifest is therefore one release artifact among several. HTTPS delivery, working application pages, appropriate icons, browser parsing, service-worker or offline behavior where required, and testing on target devices remain separate responsibilities. Passing a local checklist should lead to browser testing, not replace it.

How to Use This Tool:

Draft the public identity first, then align the routes and assets that the installed application will actually use.

Enter the App name, a concise Short name, and the public description. Keep the short label under device review even when the checklist marks 12 or fewer characters as ready.
Set the Manifest file path, Start URL, Navigation scope, and Stable app ID. Correct any same-origin or out-of-scope warning before treating the routes as release-ready.
Choose the Display mode and icon profile, then enter an icon prefix without a size suffix or extension. The generated asset rows show the exact 192 by 192 and 512 by 512 filenames that still need to exist.
Add language, direction, orientation, display override, shortcuts, or screenshots only when the release needs them. Shortcut rows use Name | URL | Description | Short name; screenshot rows use src | sizes | wide or narrow | label.
Read the Install checklist before copying the manifest. Resolve Review findings deliberately, create every listed asset, publish the file and install markup, then inspect the parsed result in each target browser.

Interpreting Results:

The generated JSON and page-head markup are drafts ready for deployment review. The status summarizes local checks only. Ready means a configured value passed that check, Review marks a choice that may be valid but needs attention, and Info records an optional omission or context.

Use the manifest member count as an inventory, not a quality score. More members do not make an application more installable.
Confirm every icon and screenshot path against deployed files. The asset ledger predicts filenames but does not create or fetch them.
Treat a zero-review checklist as permission to begin browser testing, not proof that installation, offline use, or platform support will succeed.

Technical Details:

A manifest is a JSON object linked from HTML with rel="manifest". Empty optional values are omitted, while selected display and resource settings become manifest members. Readable formatting inserts indentation; minification changes whitespace only.

Transformation Core:

The transformation turns release choices into three related records. This separation makes it possible to review the publishable file without confusing it with local readiness advice.

Web app manifest transformation stages
Stage	Transformation	Result
Normalize	Trim public text, normalize path-like values, keep supported enum choices, and remove an icon extension or size suffix from the filename prefix.	Consistent manifest inputs
Assemble	Drop empty optional members, generate selected icon entries, and keep only complete shortcut and screenshot rows.	Manifest JSON
Advertise	Escape the manifest path and theme color for HTML attributes.	`<link rel="manifest">` and optional theme-color markup
Review	Apply local rules to identity, routes, display, colors, resources, and optional metadata.	Readiness counts, checklist, and asset ledger

Rule Core:

These rules explain the status without implying that every warning is a Web App Manifest conformance error.

Local web manifest readiness rules
Check	Ready condition	Review condition
Launcher label	The supplied short name has no more than 12 characters; a blank short name does not trigger length review	The short name exceeds 12 characters and may truncate on compact surfaces
Launch boundary	The start URL has the same origin as the scope and its path equals or begins beneath the scope path	The launch path falls outside that boundary
Stable identity	An explicit app ID is present	The ID is omitted and identity may fall back to launch-route behavior
Display	`standalone`, `minimal-ui`, or `fullscreen`	`browser`, because normal browser chrome remains
Icons	Generated entries include 192 by 192 and 512 by 512 sizes; a maskable entry is separately checked	No maskable entry is generated when adaptive artwork may be needed
Colors and language	Colors use opaque six-digit hex and a supplied language tag matches the supported structural pattern	A different color form or malformed supplied language tag is retained but flagged
Optional resources	Shortcut rows contain a name and in-scope URL; screenshots contain a source and sizes, with labels preferred	Rows are incomplete, shortcuts leave scope, or complete screenshots lack labels

The selected display override is emitted before the main display mode so a supporting browser can try the override and retain the primary mode as fallback. Standard and maskable icon profiles generate separate PNG entries rather than claiming that one artwork file is safe for both purposes.

Limitations and Privacy Notes:

The review is static. It does not fetch URLs, parse the deployed response, inspect image artwork, test HTTPS, register a service worker, or reproduce browser-specific install criteria.

Generated paths can point to missing or unsuitable resources until they are created and deployed.
Newer manifest members and display modes may be ignored by browsers that do not support them.
Inputs are processed in the browser, but copied or downloaded output can contain any identifiers or private routes entered into the manifest. Keep account IDs, tokens, and campaign data out of stable launch URLs.

References:

Web Application Manifest, World Wide Web Consortium.