Share integration needs a service worker workflow, not just a manifest entry

System share dialogs are how users move content between apps on modern OS platforms. When your PWA appears there, it joins the daily workflow—but the manifest entry alone isn't enough to deliver a reliable share experience.

Why this matters

The shared experience feels broken when a share target app opens but doesn't receive the shared content, shows an error, or asks users to manually paste what they thought was being passed through. Users react the same way to dead share flows as to broken web links: they try once, then uninstall.

The MDN Web App Manifest share_target member enables this integration, but it has three conditions and gotchas that trip up PWA builders:

• Only installed PWAs can act as share targets—the browser and OS filter uninstalled apps from the share dialog regardless of manifest quality.
• HTTP method choice matters—GET passes data in URL query parameters, but POST with multipart/form-data is required for file shares and for apps that modify state (like saving a bookmark).
• Service worker interception is the reliable path—POST requests don't automatically reach client-side JavaScript, and server-side processing leaves offline users with no share fallback.

A share integration checklist

Test these scenarios before promoting "share to our PWA" as a feature:

• [ ] Install requirement: Your PWA must be installed on the share source device; verify by uninstalling and confirming it disappears from the share dialog.
• [ ] GET vs POST decision: Use GET for simple data (title, text, URL) and POST for file uploads or state-changing actions (bookmarks, database writes).
• [ ] Method alignment: If using POST, enctype must be "multipart/form-data" to support file shares.
• [ ] Service worker interception: Add a fetch event listener that handles POST share requests and redirects to a displayable URL with HTTP 303 to avoid re-submission on page reload.
• [ ] File acceptance: Define accept arrays with both MIME types ("text/csv") and extensions (".csv") because OS platforms differ in which they prefer.
• [ ] Form field names: Map manifest params keys to query parameter names (GET) or form field names (POST); verify with a manual share test.
• [ ] Offline path: Either mirror server-side POST handling in the service worker or write shared files to Cache/IndexedDB and notify clients via Client.postMessage().
• [ ] Validation: Treat all incoming share data as untrusted; validate URLs, sanitize text, and reject malformed file types before processing.

What this means for install conversion

The share dialog is a system-level discovery surface. When your PWA appears there after install, it gets placement alongside native apps that users trust to handle shared content reliably. If your share integration misfires—missing content, silent errors, or prompting the user to "paste it here"—you lose a trust signal that's hard to rebuild.

From a marketplace review standpoint, share_target entries that reference invalid actions, missing params, or POST endpoints without service worker handling should be flagged as incomplete. The entry exists, but the workflow doesn't.

What to avoid

Don't add a share_target manifest member to satisfy a PWA checklist if your PWA isn't installed, can't handle the data, or doesn't validate inputs. A dead share entry in the system dialog looks worse than no entry at all.

Next steps

Read the full MDN share_target guide to understand the security and offline considerations. Don't ship share integration without a real install test on at least two OS platforms—Android and desktop.