This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.
The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.
This is a work in progress. Wide review and feedback welcome.
This example shows a basic share operation. In response to a button click, this JavaScript code shares the current page's URL.
shareButton.addEventListener("click", async () => { try { await navigator.share({ title: "Example Page", url: "" }); console.log("Data was shared successfully"); } catch (err) { console.error("Share failed:", err.message); } });
Note that a {{ShareData/url}} of `''` refers to the current page URL, just as it would in a link. Any other absolute or relative URL can also be used.
In response to this call to {{Navigator/share()}}, the user agent would display a picker or chooser dialog, allowing the user to select a target to share this title and the page URL to.
partial interface Navigator { [SecureContext] Promise<undefined> share(optional ShareData data = {}); };
User agents that do not support sharing SHOULD NOT expose {{Navigator/share()}} on the {{Navigator}} interface.
This API adds the following internal slot to the {{Navigator}} interface.
When the {{Navigator/share()}} method is called with argument |data:ShareData|, run the following steps:
The user agent MUST NOT allow the website to learn which share targets are available, or the identity of the chosen target.
dictionary ShareData { sequence<File> files; USVString title; USVString text; USVString url; };
The ShareData dictionary consists of several optional members:
A share target is the abstract concept of a destination that the user agent will transmit the share data to. What constitutes a share target is at the discretion of the user agent.
A share target might not be directly able to accept a {{ShareData}} (due to not having been written with this API in mind). However, it MUST have the ability to receive data that matches some or all of the concepts exposed in {{ShareData}}. To convert data to a format suitable for ingestion into the target, the user agent SHOULD map the members of {{ShareData}} onto equivalent concepts in the target. It MAY discard or combine members if necessary. The meaning of each member of the payload is at the discretion of the share target.
Each share target MAY be made conditionally available depending on the {{ShareData}} payload delivered to the {{Navigator/share()}} method.
The list of share targets can be populated from a variety of sources, depending on the user agent and host operating system. For example:
In some cases, the host operating system will provide a sharing or intent system similar to Web Share. In these cases, the user agent can simply forward the share data to the operating system and not talk directly to native applications.
This specification defines a policy-controlled permission identified by
the string "web-share
". Its default
allowlist is '`self`'.
A document’s permission policy determines whether a {{Navigator/share()}} call immediately rejects with a {{"NotAllowedError"}} {{DOMException}}.
When this specification is used to present information in the user interface, implementors will want to follow the OS level accessibility guidelines for the platform.
Web Share enables data to be sent from websites to native applications. While this ability is not unique to Web Share, it does come with a number of potential security issues that can vary in severity (depending on the underlying platform).
Share targets that dereference a shared URL and forward that information on might inadvertently forward information that might be otherwise confidential. This can lead to unexpected information leakage if shares reference content that is only accessible by that application, the host on which it runs, or its network location.
Malicious sites might exploit share targets that leak information by providing URLs that ultimately resolve to local resources, including, but not limited to, "file:" URLs or local services that might otherwise be inaccessible. Even though this API limits shared URLS to "http:" and "https:", use of redirects to other URLs or tweaks to DNS records for hosts in those URLs might be used to cause applications to acquire content.
To avoid being used in these attacks, share targets can consume the URL, retrieve the content, and process that information without sharing it. For instance, a photo editing application might retrieve an image that is "shared" with it. A share target can also share the URL without fetching any of the referenced content.
Share targets that fetch content for the purposes of offering a preview or for sharing content risk information leakage. Content that is previewed and authorized by a user might be safe to forward, however it is not always possible for a person to identify when information should be confidential, so forwarding any content presents a risk. In particular, the {{ShareData/title}} might be used by an attacker to trick a user into misinterpreting the nature of the content.
The Web Share API is designed to be extended in the future by way of new members added to the {{ShareData}} dictionary, to allow both sharing of new types of data (e.g., images) and strings with new semantics (e.g. author).
The three members {{ShareData/title}}, {{ShareData/text}}, and {{ShareData/url}}, are part of the base feature set, and implementations that provide {{Navigator/share()}} need to accept all three. Any new members that are added in the future will be individually feature-detectable, to allow for backwards-compatibility with older implementations that don't recognize those members. These new members might also be added as optional "MAY" requirements.
The {{Navigator/share()}} method returns a rejected promise with a {{TypeError}} if none of the specified members are present. The intention is that when a new member is added, it will also be added to this list of recognized members. This is for future-proofing implementations: if a web site written against a future version of this spec uses only new members (e.g., `navigator.share({image: x})`), it will be valid in future user agents, but a {{TypeError}} on user agents implementing an older version of the spec. Developers will be asked to feature-detect any new members they rely on, to avoid having errors surface in their program.
Editors of this spec will want to carefully consider the genericity of any new members being added, avoiding members that are closely associated with a particular service, user agent or operating system, in favour of members that can potentially be applied to a wide range of platforms and targets.
Thanks to the Web Intents team, who laid the groundwork for the web app interoperability use cases. In particular, Paul Kinlan, who did a lot of early advocacy for Web Share.