Wiki · Concept · Last reviewed June 25, 2026

Web Share Target API

The Web Share Target API lets an installed web app register as a receiver for content shared from other apps or browser share flows.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser API, progressive web apps, sharing, installed web apps, agents, data handoff

Definition

The Web Share Target API is the receiving side of web sharing. The Web Share API lets a page send text, URLs, or files to a user-chosen destination. Web Share Target lets an installed progressive web app become one of those destinations. The W3C Level 2 draft defines an API that allows websites to declare themselves as share targets, able to receive shared content from the Web Share API or system share events.

The declaration lives in the Web App Manifest as share_target. MDN describes this manifest member as a way for installed PWAs to be registered in the system share dialog alongside native targets such as email or messaging apps. The result is an inbound handoff boundary: content leaves one app context and arrives in a web app that may be backed by service workers, storage, accounts, and agents.

How It Works

The share_target member defines an action URL, an HTTP method, optional enctype, and params that map shared fields such as title, text, URL, and files into request names. MDN documents GET handling for basic text and links, where the app is launched with query parameters. It also documents POST handling for richer payloads, including form-encoded or multipart submissions.

Chrome documentation frames the feature as allowing installed web apps to register with the underlying operating system as share targets. For POST-based file shares, a service worker can intercept the request, extract the shared data, and route the user to an application page. That makes Web Share Target especially relevant to static apps and offline-first PWAs: the incoming share can be captured at the service-worker boundary before the visible app page renders.

Agent Context

For AI Browsers and Computer Use, Web Share Target is an ingestion surface. A user can share a contract, screenshot, link, voice memo, calendar detail, product page, bug report, or email fragment into an installed web app. If that app contains an assistant, the assistant may summarize, classify, store, forward, translate, extract entities, or start a workflow from the shared material.

This is useful, but it is not ordinary page input. The user may be acting from another app and may see only a compact share sheet. The receiving PWA may infer more than the user expects, especially when it combines incoming text with account memory, previous files, browser state, or organization policy. A governed agent must treat inbound shares as scoped evidence, not as blanket permission to analyze or retain everything attached.

Governance Use

A governed deployment should review the declared share_target before installation is promoted. The accepted data types should match the app's purpose, the action URL should route to a clear import path, and the app should preview incoming material before model processing or onward transmission. For sensitive contexts, the receiving page should show where the share came from when available, what fields arrived, and what the agent is about to do.

Organizations should pair Web Share Target with data minimization, retention limits, and incident review. It should be possible to distinguish a user sharing a document into a workspace from an agent uploading that document to a model provider, saving a copy, or forwarding derived content elsewhere.

Limits

Web Share Target requires installation and depends on browser and operating-system support. MDN marks share_target as experimental and not Baseline because it is not supported in some widely used browsers. The W3C draft defines the manifest and request model, but user agents and operating systems still decide presentation, picker behavior, and integration details.

The API is also not a security review. It does not validate file contents, prove the user's intent beyond choosing a share target, prevent prompt injection in shared text, or decide whether received data may be sent to a model. It creates an intake path. Governance must decide what happens after intake.

Minimum Evidence Record

For an agent-facing share target, record the manifest URL, app id if present, origin, share_target.action, method, enctype, accepted fields, file count and type categories, OS or browser share surface when available, receiving service-worker event if used, user confirmation, model-upload decision, retention class, agent task identifier, and any rejected or cancelled share.

Source Discipline

Use the W3C and WICG Web Share Target specifications for the manifest member and processing model. Use MDN for developer-facing summaries, GET and POST examples, installation requirement, and compatibility warnings. Use Chrome documentation for implementation notes about operating-system share targets, installability, service-worker handling, and file scenarios.

Spiralist Reading

Spiralism reads Web Share Target as the inbox side of the share ritual. A user sends a fragment from one context into another, and the receiving app gives that fragment a new institutional life. In an agentic browser, the ethical question is not whether sharing is convenient. It is whether the receiving system tells the truth about what it accepted, what it inferred, and what it kept.

Sources

Return to Wiki