1. Core Setup
Start with these fields first. They cover the basics every installable app needs.
The main display name of your app. Anywhere your app name appears, this value is used. Use at least 2 characters.
A shorter app name used where space is limited (for example below an icon). PWABuilder packaging expects this, and many store surfaces look better with it. Keep it around 3 to 12 characters.
The logos for your app used in varying contexts like the desktop taskbar or mobile home screen. You need at least one "any" purpose icon, and one large one (preferably 512x512). The path can be relative (e.g. /images/icon.png) or absolute (e.g. https://mysite.com/icon.png).
Need help choosing icon values?
Use purpose: any for a normal icon. Use purpose: maskable for a separate icon with safe padding so Android can crop it cleanly.
src is the image path. sizes is the real pixel size like 192x192 or 512x512. type is usually image/png.
Path tip: Use /icons/app-512.png for same-site files, or a full URL like https://example.com/icons/app-512.png.
A short summary of what your app does. This helps users trust your app and improves how your app appears in install prompts and store listings.
The exact page that loads when a user taps your app's icon to open it. Usually, you want this to be / (your homepage).
Path tip: Use / for your home page, /app for an app shell route, or a full URL if needed.
A hidden ID for your app telling browsers it's the same app even if you change its name later. Allows the browser to properly associate your app's identity with a specific install. Defaults to /?homescreen=1.
2. App Window And Navigation
These options control how your app opens, looks, rotates, and navigates.
How your app should behave when opened:
standalone: Looks like a real app, in its own window, hiding the browser's URL bar.
fullscreen: Hides the URL bar AND the system clock/battery bar. Uses all display space.
minimal-ui: Looks mostly like an app but keeps a minimal back/refresh button.
browser: Just opens like a normal webpage layout in a standard browser window (Default).
A fallback list if your device doesn't support the display mode above (comma separated). Also accepts window-controls-overlay for a desktop-only display mode that adds a native-style overlay to the top of your application.
The page color of the window that flashes on screen before your site finishes loading/styles are loaded. Should match your site's dark or light theme.
Changes the default color used by OS features. For example, the top window title bar when the application is installed on Windows.
Force the app to launch sideways or vertically.
any: Your app can rotate to whichever orientation the device supports.
natural: Locks to the device's natural default orientation (usually portrait on phones, often landscape on some tablets).
portrait: Forces the phone vertically.
landscape: Forces the phone horizontally (like a game).
What is the difference between any and natural?
any means rotation is allowed. If the user rotates the device, your app rotates too.
natural means keep the built-in default direction for that device model. It does not freely rotate like any.
Which way the text in the manifest should be read.
The primary language your app is written in (expects a proper BCP47 subtag for each language). If your site has multiple languages, pick the main one.
3. Store Readiness And Discovery
These fields improve store presentation and user discoverability, but are not strictly required.
The categories your app fits into (e.g. games, finance, productivity, navigation).
Defines the navigation URLs that are inside the "borders" of your app. If the user navigates outside of your app's scope, they will be navigated to a normal browser window. Usually can just be set to the base URL.
Path tip: Most apps can use /. You can restrict to a folder like /app/ if needed.
A list of key tasks within your application. These shortcuts can be displayed by the operating system to allow a user to launch directly to a specific part of the application (e.g. a right-click menu or long-hold menu).
Path tip: Shortcut URL should usually be a path like /about or /new-message. Icon source path follows the same rule as normal icons.
Screenshots help users understand your app before installing it. They improve trust and can improve store conversion.
What should I put for Type and Platform?
Type is the image format, like PNG or JPEG.
Platform is a display hint. Use wide for landscape images, narrow for portrait images. If unsure, leave platform empty.
Path tip: Use /screenshots/home.png for local files, or a full URL like https://example.com/screenshots/home.png.
4. Advanced Capabilities (Safe To Skip)
If you are not sure what these do, leave them empty. Your manifest will still be valid and useful. Some of these are covered in deeper capability docs, not always in basic quick-start documentation.
Allows your app to control multiple subdomains (like a blog and a shop) and top-level domains as one single entity.
When should I use this?
Use this only if your app must open links across different origins in one app experience. You also need a .well-known/web-app-origin-association file on each associated origin.
Controls what happens when users launch the app while it is already open. You can choose one mode or provide a fallback priority list.
Which launch mode should I pick?
focus-existing: keep app state, focus recent window.
navigate-existing: reuse recent window and navigate it to the launch URL.
navigate-new: open a brand new app window each launch.
If you want compatibility fallback, use the optional list: for example future-mode, focus-existing, auto.
Specifies whether your app supports the side panel view in Microsoft Edge for side-by-side browsing. Set your preferred width here in pixels.
Specify native or related apps (like Play Store or Microsoft Store). Platform and URL are usually enough; ID is optional on some platforms.
Path tip: URL should be a full listing link like https://play.google.com/store/apps/details?id=com.example.
Specifies whether or not related_applications should be preferred. If set to true, the browser may recommend downloading your natively built app INSTEAD of this web app.
Lets your app handle custom links like web+music://artist. Most apps do not need this unless you own a custom URL protocol.
Path tip: URL should usually be an in-app route like /play?track=%s. Keep the %s placeholder so the clicked protocol URL is passed in.
In plain English: do I need this?
Only if you want links outside your app to open directly into your PWA using a custom protocol.
If you are unsure, skip it.
Defines which files your app can open from the OS file picker or desktop explorer. This is mostly useful for desktop-class apps (editors, viewers, design tools).
Path tip: Action URL should be an in-app route like /open-file. Icon source path follows the same icon path rules.
How do MIME types and extensions work here?
Use MIME type as the key and extension list as values. Example: application/pdf with .pdf.
For multiple extensions in one handler, separate with commas like .stl, .fbx.
If this still feels advanced, leave it empty and come back later.
Lets users share text, links, or files from other apps directly into your PWA. Great for notes, messaging, and content apps, but safe to skip for simple websites.
Path tip: Action URL should point to a route in your app that handles incoming shared data, such as /handle-share.
When do I use POST and multipart/form-data?
Use GET for plain text/url sharing. Use POST when files or binary content are shared.
If files are shared, set encoding to multipart/form-data.
If your app does not need "Share to app" behavior from the OS, skip this entire section.
If your app supports instant note creation, set the URL that opens a "new note" screen.
Path tip: Use an in-app path like /notes/new.
Widget metadata for supported platforms (mainly advanced Windows scenarios). Most apps can skip this.
Path tip: Widget template or data URLs can be relative (like /widgets/weather.json) or full URLs.
Do I need widgets?
No, not for most PWAs. Only use this if you are intentionally building widget support for specific platforms.
The IARC age rating assigned to your app if you submitted a questionnaire to specify a suitable age range.
JSON Preview
{}