Web Share API

1. Usage Examples

This section is non-normative.

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 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 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.

5. Accessibility considerations

This section is non-normative.

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.

6. Security and privacy considerations

This section is non-normative.

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).

• There is a requirement to not allow the website to learn which apps are installed, or which app was chosen from share(), because this information could be used for fingerprinting, as well as leaking details about the user's device.
• Implementors will want to carefully consider what information is revealed in the error message when share() is rejected. Even distinguishing between the case where no targets are available and user cancellation could reveal information about which apps are installed on the user's device.
• There is a requirement that share() presents the user with a dialog asking them to select a target application (even if there is only one possible target). This surface serves as a security confirmation, ensuring that websites cannot silently send data to native applications.
• Due to the capabilities of the API surface, share() is available only in secure contexts (such as https:// schemes).
• Use of share() from a private browsing mode might leak private data to a third-party application that does not respect the user's privacy setting. User agents could present additional warnings or disable the feature entirely when in a private browsing mode, but this is not mandated as the chooser UI could be considered sufficient warning.
• The data passed to share() might be used to exploit buffer overflow or other remote code execution vulnerabilities in native applications that receive shares. There is no general way to guard against this, but implementors will want to be aware that it is a possibility.

• 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 title might be used by an attacker to trick a user into misinterpreting the nature of the content.