CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 date: Thu, 09 Oct 2025 14:47:04 GMT content-type: text/html; charset=utf-8 content-encoding: gzip content-location: Overview.html last-modified: Tue, 17 Dec 2019 08:28:34 GMT cache-control: max-age=31536000 expires: Fri, 09 Oct 2026 14:47:04 GMT vary: Accept-Encoding,Origin link: ;rel="timegate", ;rel="original" access-control-allow-origin: * memento-datetime: Tue, 17 Dec 2019 08:28:34 GMT x-backend: www-mirrors x-request-id: 98beabc93cdc1eef strict-transport-security: max-age=15552000; includeSubdomains; preload content-security-policy: frame-ancestors 'self' https://cms.w3.org/ https://cms-dev.w3.org/; upgrade-insecure-requests cf-cache-status: BYPASS set-cookie: __cf_bm=xHxuKPa4LXLyxE4RwdggV55o9EFXA6UamYN2cQtvNZw-1760021224-1.0.1.1-LKz7bXtt8OeDVLQJIJ9FkaSdrEiwvLPo9ePhQJJ6DikJuMAuL9JwkZrTubSzhZcXZHbKME568Nj4XMv.mjzuRm_rAthqwXUuGJ8PbxkgbYg; path=/; expires=Thu, 09-Oct-25 15:17:04 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None server: cloudflare cf-ray: 98beabc93cdc1eef-BLR alt-svc: h3=":443"; ma=86400 Web Share API

Web Share API

W3C First Public Working Draft 17 December 2019

This version:: https://www.w3.org/TR/2019/WD-web-share-20191217/
Latest published version:: https://www.w3.org/TR/web-share/
Latest editor's draft:: https://w3c.github.io/web-share/
Test suite:: https://w3c-test.org/web-share/
Editor:: Matt Giuca (Google Inc.)
Participate:: GitHub w3c/web-share; File a bug; Commit history; Pull requests
Browser support:: caniuse.com

Abstract

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.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This is a work in progress. Wide review and feedback welcome.

This document was published by the Web Applications Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

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.

Example 1: Basic usage

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.

2. API definition

2.1 Extensions to the `Navigator` interface

partial interface Navigator {
  [SecureContext] Promise<void> share(optional ShareData data = {});
};

User agents that do not support sharing SHOULD NOT expose share() on the Navigator interface.

Note

The above statement is designed to permit feature detection. If share() is present, there is a reasonable expectation that it will work and present the user with at least one share target. Clients can use the presence or absence of this method to determine whether to show UI that triggers its use.

2.1.1 Internal Slots

This API adds the following internal slot to the Navigator interface.

Promise? [[sharePromise]]: The [[sharePromise]] is a promise that represents a user's current intent to share some data with a share target. It is initialized to null.

When the share() method is called with argument data, run the following steps:

If [[sharePromise]] is not null, return a promise rejected with InvalidStateError.
If none of data's members title, text, or url are present, return a promise rejected with a TypeError.
If data's url member is present:
1. Let base be the this value's relevant settings object's api base URL.
2. Let url be the result of running the URL parser on data's url with base.
3. If url is failure, return a promise rejected with TypeError.
4. Set data to a copy of data, with its url member set to the result of running the URL serializer on url.
If the relevant global object of this does not have transient activation, return a promise rejected with with a "NotAllowedError" DOMException.
Set [[sharePromise]] to be a new promise.
Return [[sharePromise]] and in parallel:
1. If there are no share targets available:
  1. Reject [[sharePromise]] with an "AbortError" DOMException.
  2. Set [[sharePromise]] to null.
  3. Abort these steps.
2. Present the user with a choice of one or more share targets, selected at the user agent's discretion. The user MUST be given the option to cancel rather than choosing any of the share targets. Wait for the user's choice.
3. If the user chose to cancel the share operation:
  1. Reject [[sharePromise]] with an "AbortError" DOMException,
  2. Set [[sharePromise]] to null.
  3. Abort these steps.
4. Activate the chosen share target, convert data to a format suitable for ingestion into the target, and transmit the converted data to the target.
5. If an error occurs starting the target or transmitting the data:
  1. Reject [[sharePromise]] with an "DataError" DOMException.
  2. Set [[sharePromise]] to null.
  3. Abort these steps.
6. Once the data has been successfully transmitted to the target, resolve [[sharePromise]] with undefined.
7. Set [[sharePromise]] to null.

The user agent MUST NOT allow the website to learn which share targets are available, or the identity of the chosen target.

Note

share() always shows some form of UI, to give the user a choice of application and get their approval to invoke and send data to a potentially native application (which carries a security risk). For this reason, user agents are prohibited from showing any kind of "always use this target in the future" option, or bypassing the UI if there is only a single share target.

2.2 `ShareData` dictionary

dictionary ShareData {
  USVString title;
  USVString text;
  USVString url;
};

The ShareData dictionary consists of several optional members:

text member: Arbitrary text that forms the body of the message being shared.
title member: The title of the document being shared. May be ignored by the target.
url member: A URL string referring to a resource being shared.

Note

These members are USVString (as opposed to DOMString) because they are not allowed to contain invalid UTF-16 surrogates. This means the user agent is free to re-encode them in any Unicode encoding (e.g., UTF-8).

Note

The url member can contain a relative-URL string. In this case, it will be automatically resolved relative to the current page location, just like a href on an a element, before being given to the share target.

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.

Note

Mapping the ShareData to the share target's (or operating system's) native format can be tricky as some platforms will not have an equivalent set of members. For example, if the target has a "text" member but not a "URL" member (as is the case on Android), one solution is to concatenate both the text and url members of ShareData and pass the result in the "text" member of the target.

Each share target MAY be made conditionally available depending on the ShareData payload delivered to the share() method.

Note

Once a share target has been given the payload, the share is considered successful. If the target considers the data unacceptable or an error occurs, it can either recover gracefully, or show an error message to the end-user; it cannot rely on the sender to handle errors. In other words, the share() method is "fire and forget"; it does not wait for the target to approve or reject the payload.

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

A. Extensibility of this API

This section is non-normative.

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

Warning

This doesn't mean user agents can add whatever members they like. It means that new members can be added to the standard in the future.

The three members title, text, and url, are part of the base feature set, and implementations that provide 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.

Note

There is an open discussion about how to provide feature-detection for dictionary members. Web Share will use the mechanism produced by that discussion.

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

B. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

C. IDL Index

partial interface Navigator {
  [SecureContext] Promise<void> share(optional ShareData data = {});
};
dictionary ShareData {
  USVString title;
  USVString text;
  USVString url;
};

D. Acknowledgments

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.

E. References

E.1 Normative references

[html]: HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[url]: URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[WebIDL]: Web IDL. Boris Zbarsky. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/

E.2 Informative references

[rfc2781]: UTF-16, an encoding of ISO 10646. P. Hoffman; F. Yergeau. IETF. February 2000. Informational. URL: https://tools.ietf.org/html/rfc2781
[rfc3629]: UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. November 2003. Internet Standard. URL: https://tools.ietf.org/html/rfc3629

Original Source | Taken Source

Web Share API

W3C First Public Working Draft 17 December 2019

Abstract

Status of This Document

1. Usage Examples

2. API definition

2.1 Extensions to the Navigator interface

2.1.1 Internal Slots

2.1.2 share() method

2.2 ShareData dictionary

3. Share targets

3.1 Examples of share targets

4. Security and privacy considerations

A. Extensibility of this API

B. Conformance

C. IDL Index

D. Acknowledgments

E. References

E.1 Normative references

E.2 Informative references

2.1 Extensions to the `Navigator` interface

2.1.2 `share()` method

2.2 `ShareData` dictionary