How to Configure Web Share Target in Android PWAs

Understanding Web Share Target on Android

The Web Share Target API allows a Progressive Web App (PWA) to register itself with the host operating system as a receiver of shared content. On Android, when a user clicks the system share button inside a photo gallery, web browser, or social media app, your converted Trusted Web Activity (TWA) can appear in the native share sheet. This turns your web application into an active participant in the Android ecosystem, removing the functional gap between web code and native packages.

When a user selects your app from the share sheet, the Android system launches your TWA and transmits the shared content directly to your web application via a standard HTTP request. Depending on your configuration, this payload can contain plain text, URLs, or binary files such as images, audio tracks, and PDF documents.

Configuring the Web App Manifest

To enable share target capabilities, you must define the share_target member in your web app manifest file (typically manifest.json). This configuration tells the system browser and the TWA shell what types of data your application can accept and where to send the payload when a share event occurs.

The share_target object requires an action URL, a transmission method, and a params definition mapping native share data fields to web query parameters. Here is a basic example of a manifest configuration for handling text and URLs:

{ "name": "My Social App", "short_name": "SocialApp", "start_url": "/", "display": "standalone", "share_target": { "action": "/share-handler", "method": "GET", "params": { "title": "title", "text": "text", "url": "url" } } }

In this configuration, when a user shares a link or text to your app, the Android device launches the PWA at the path specified in the action field, appending the shared parameters as query parameters. For example: /share-handler?title=Check+this+out&url=https%3A%2F%2Fexample.com.

Handling Share Payloads with HTTP GET

Using the GET method is the most straightforward approach for processing simple data points like links and short texts. When your application loads the specified action URL, your frontend Javascript must parse the query string and render the corresponding UI.

You can capture these values directly from the window location using standard web APIs. Here is an example of how to handle the incoming data on your receiving page:

window.addEventListener('DOMContentLoaded', () => { const parsedUrl = new URL(window.location.href); const sharedTitle = parsedUrl.searchParams.get('title'); const sharedText = parsedUrl.searchParams.get('text'); const sharedUrl = parsedUrl.searchParams.get('url'); if (sharedTitle || sharedText || sharedUrl) { showShareForm({ title: sharedTitle, text: sharedText, url: sharedUrl }); } });

This logic reads the URL parameters immediately upon load. If any share data exists, it populates a share dialogue, compose box, or draft post interface, creating a seamless user transition from the originating app into your web platform.

Handling Complex Data and File Shares with POST

If your application needs to receive media files, documents, or larger datasets, the HTTP GET method is insufficient due to URL length limitations and the inability to pass binary data. You must use the HTTP POST method combined with multipart form data encoding.

To configure your manifest for receiving files, you need to extend the share_target object to define the accepted mime-types and file parameter keys:

"share_target": { "action": "/incoming-share", "method": "POST", "enctype": "multipart/form-data", "params": { "title": "title", "text": "text", "files": [ { "name": "media", "accept": ["image/jpeg", "image/png", "image/gif"] } ] } }

Processing POST Shares inside a Service Worker

Because static web servers generally do not process POST requests dynamically at runtime, your PWA's Service Worker must intercept the POST request, retrieve the shared files from the request body, and store or redirect them appropriately.

The service worker intercepts the fetch event for the action URL, handles the form data parsing, and redirects the user back to an addressable GET route while passing the data via the Cache API, IndexedDB, or client messaging.

self.addEventListener('fetch', (event) => { const url = new URL(event.request.url); if (event.request.method === 'POST' && url.pathname === '/incoming-share') { event.respondWith( (async () => { const formData = await event.request.formData(); const file = formData.get('media'); const title = formData.get('title'); const text = formData.get('text'); const cache = await caches.open('incoming-shares'); if (file) { await cache.put('/shared-file', new Response(file)); } return Response.redirect('/share-confirmation?hasFile=true', 303); })() ); } });

Once redirected to the confirmation page, your client-side JavaScript can fetch the cached file blob from /shared-file and display or upload it as needed.

Mapping Share Targets to Your Android Package

When you build a Trusted Web Activity package using PWAtoApp, the compiler reads your Web App Manifest to generate the corresponding Android intents. The resulting APK and Google Play ready AAB contain specific Intent Filters mapped to your domain.

Because this connection relies heavily on matching security declarations, you must have Digital Asset Links correctly verified. If your Digital Asset Links are not properly configured, Android will not trust your application, which can cause the share target intent to fail or open in a standard browser tab instead of your fullscreen TWA container.

Testing the Android Share Intent

To verify that your Web Share Target is working correctly inside your TWA wrapper:

• Deploy your updated manifest.json and Service Worker code to your live production domain.
• Install your generated APK or AAB on an Android device or virtual emulator.
• Open a different native application, such as Google Photos or Chrome.
• Select a piece of text or an image, click Share, and locate your PWA in the system share dialogue.
• Tap your application icon and verify that the share payload is processed without launching external browser bars.

By implementing the Web Share Target API, your converted web app functions identically to native software, allowing users to move content seamlessly into your workflow with native system integrations.