Web App Manifest URL and Scope Workbench

How to use Web App Manifest URL and Scope Workbench

Inspect selected manifest members, resolve launch/icon URLs and test navigation targets against the declared scope. Supply both manifest and document URLs so their different resolution roles stay explicit. Review cross-origin fallbacks, origin-based application IDs and literal scope-prefix behavior before publishing a PWA manifest.

1. Provide web app manifest json, manifest url, document url, navigation targets, one per line.
2. Choose the supported mode and run the tool. Review its assumptions and any reported errors.
3. Copy the result or download a separate output; reset to clear the current form.

Good to know

• 100 KB of duplicate-free JSON and 40 parsed levels. Member/URL strings are at most 4,000 UTF-8 bytes; at most 100 icons and 100 navigation targets. Prototype-related JSON keys are refused.
• This HTTP(S)-only offline profile does not fetch or install a manifest. Unsupported schemes/credentials in selected member URLs are reported as unusable; supplied manifest, document and navigation URLs must be usable HTTP(S) inputs.
• The modeled subset covers base launch URL, scope, fragment-excluded identity comparison, basic text/direction/language/display/orientation preferences and inert icon metadata. Other members remain listed as unmodeled, not silently certified.
• Scope is a same-origin literal pathname prefix, so /app can include /apple. Default scope uses the selected start URL directory; id resolves from that URL’s origin rather than the manifest directory.
• Icon declarations are not proof of actual pixel dimensions, MIME type, safe-zone geometry, usable files or platform support. No installability, offline support, CORS/CSP or service-worker verdict is produced.
• Inputs are processed on this device and are not automatically saved or uploaded.