midPWA

Web App Manifest advanced features?

Updated May 17, 2026

Short answer

A Web App Manifest is a JSON file that controls how a Progressive Web App (PWA) is installed and presented to users. Advanced manifest features include app shortcuts, file handling, URL protocol handling, display modes, related applications, screenshots, share targets, and platform integration capabilities. These features improve discoverability, native-like behavior, and integration with the operating system while keeping the app web-based.

Deep explanation

The Web App Manifest (manifest.json or another JSON resource linked from HTML) provides metadata that browsers use to understand how a PWA should behave when installed. While basic fields like name, icons, and start_url enable installation, advanced features allow deeper integration with the device and operating system.

A typical manifest is linked from the application HTML:

HTML
<link rel="manifest" href="/manifest.json">

A browser reads the manifest during PWA installation and uses supported fields to configure the installed experience. Support varies by browser and operating system, so advanced features should always have graceful fallbacks.

App Shortcuts

The shortcuts member allows a PWA to expose quick actions from the operating system's app launcher, context menus, or long-press menus.

Example:

JSON
{
  "name": "Shopping App",
  "shortcuts": [
    {
      "name": "Search Products",
      "short_name": "Search",
      "url": "/search",
      "icons": [
        {
          "src": "/icons/search.png",
          "sizes": "96x96"
        }
      ]
    },
    {
      "name": "View Orders",
      "short_name": "Orders",
      "url": "/orders"
    }
  ]
}

When supported, users can directly launch common tasks without opening the application homepage first.

Display Modes

The display field controls how the installed PWA appears.

JSON
{
  "display": "standalone"
}

Common values:

  • browser — Opens inside a normal browser tab.
  • standalone — Looks like a native application without the browser UI.
  • minimal-ui — Provides a reduced browser interface where supported.
  • fullscreen — Uses the entire display, commonly for games or immersive apps.

The display_override property allows developers to provide a preferred fallback sequence:

JSON
{
  "display_override": [
    "window-controls-overlay",
    "standalone"
  ],
  "display": "standalone"
}

This lets browsers choose the best supported experience.

Window Controls Overlay

For desktop PWAs, window-controls-overlay allows the application content to extend into the title bar area while still providing operating-system window controls.

JSON
{
  "display_override": [
    "window-controls-overlay"
  ]
}

Applications can then use CSS environment variables to avoid overlapping important UI:

CSS
.header {
  padding-top: env(titlebar-area-height);
}

This is useful for desktop productivity applications that want a more native layout.

File Handling

The file_handlers member allows a PWA to register itself as an application that can open certain file types.

Example:

JSON
{
  "file_handlers": [
    {
      "action": "/open-file",
      "accept": {
        "text/plain": [".txt"],
        "application/pdf": [".pdf"]
      }
    }
  ]
}

When supported, users can open compatible files from the operating system and have them routed to the PWA.

Important considerations:

  • Browser support is limited.
  • The application must still validate uploaded files.
  • File handling improves integration but does not grant unrestricted filesystem access.

URL Protocol Handling

PWAs can register custom URL protocols:

JSON
{
  "protocol_handlers": [
    {
      "protocol": "web+music",
      "url": "/open?track=%s"
    }
  ]
}

A link such as:

TypeScript
web+music://song/123

can open the installed PWA and pass the URL information to the application.

Custom protocols must use the web+ prefix for security reasons.

Share Target API

A PWA can appear as a target in the operating system's share menu.

Manifest:

JSON
{
  "share_target": {
    "action": "/share",
    "method": "POST",
    "enctype": "multipart/form-data",
    "params": {
      "title": "title",
      "text": "text",
      "url": "url"
    }
  }
}

For example, a note-taking PWA could receive shared text from another application.

The service worker or backend route handles the incoming share request and imports the content into the application.

Related Applications

The related_applications field links a PWA to native applications.

JSON
{
  "related_applications": [
    {
      "platform": "play",
      "id": "com.example.app"
    }
  ],
  "prefer_related_applications": false
}

This is useful for organizations that offer both native and web versions of their product.

If:

JSON
{
  "prefer_related_applications": true
}

is set, some browsers may prioritize directing users toward the native application instead of installing the PWA.

Screenshots and Store-Like Presentation

The screenshots field helps browsers display richer installation prompts.

JSON
{
  "screenshots": [
    {
      "src": "/screenshots/dashboard.png",
      "sizes": "1280x720",
      "type": "image/png"
    }
  ]
}

This is particularly useful on platforms that show PWA installation dialogs resembling app stores.

Orientation and Capabilities

The manifest can request preferred orientation:

JSON
{
  "orientation": "portrait"
}

Common values include:

  • portrait
  • landscape
  • any

This is useful for apps such as games, kiosks, and specialized dashboards.

Scope and Navigation Control

The scope field defines which URLs belong to the installed application.

JSON
{
  "start_url": "/app",
  "scope": "/app/"
}

A URL outside the scope may open in the normal browser instead of the installed app window.

A common mistake is incorrectly configuring scope, causing internal pages to unexpectedly leave the PWA experience.

Manifest and Service Worker Relationship

The manifest and service worker solve different problems:

FeatureManifestService Worker
Installation metadataYesNo
App name and iconsYesNo
Offline cachingNoYes
Background syncNoYes
Push notificationsNoYes
Launch behaviorYesPartially

A complete PWA typically uses both:

  • The manifest defines the app identity and OS integration.
  • The service worker provides network control and offline capabilities.

Real-world example

A project management PWA wants to behave like a desktop application. Users should be able to:

  • Launch directly into their dashboard.
  • Create a new task from the app launcher.
  • Open shared project links in the installed app.
  • Receive files exported from other applications.

Example manifest:

JSON
{
  "name": "Team Planner",
  "short_name": "Planner",
  "start_url": "/dashboard",
  "scope": "/",
  "display": "standalone",
  "icons": [
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "shortcuts": [
    {
      "name": "New Task",
      "url": "/tasks/new"
    }
  ],
  "file_handlers": [
    {
      "action": "/import",
      "accept": {
        "application/json": [".json"]
      }
    }
  ],
  "share_target": {
    "action": "/capture",
    "method": "POST",
    "params": {
      "text": "description"
    }
  }
}

The service worker would handle offline caching and background operations, while the manifest makes the application feel integrated with the user's device.

Common mistakes

  • * Treating the manifest as a replacement for a service worker
  • the manifest does not provide offline functionality.
  • * Assuming every manifest feature works identically across browsers and operating systems.
  • * Using incorrect `scope` values that cause navigation to leave the installed app experience.
  • * Providing missing or invalid icon sizes, preventing installation prompts from appearing.
  • * Setting `prefer_related_applications` without understanding that it may discourage PWA installation.
  • * Forgetting to test installed behavior after manifest changes because browsers may cache manifest data.
  • * Adding advanced capabilities without providing fallback behavior for unsupported browsers.
  • * Allowing file handlers or share targets to process untrusted input without validation.

Follow-up questions

  • How does a browser decide whether a PWA is installable?
  • What is the difference between start_url and scope in a manifest?
  • How should developers handle unsupported manifest features?
  • Why does a PWA need both a manifest and a service worker?
  • What security concerns exist with advanced manifest features?

More PWA interview questions

View all →