Near Field Communication (NFC) enables wireless communication between two devices at close proximity, usually less than a few centimeters. NFC is an international standard (ISO/IEC 18092) defining an interface and protocol for simple wireless interconnection of closely coupled devices operating at 13.56 MHz (see http://www.nfc-forum.org/specs/spec_list/).

This specification defines an API to manage selected NFC use-cases from web pages, and to enable new use-cases based on NFC technology.

Status of This Document

This specification was published by the Web NFC Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Implementors need to be aware that this specification is considered unstable. Implementors who are not taking part in the discussions will find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should subscribe to the repository on GitHub and take part in the discussions.

Significant changes to this document since last publication are documented in the Changes section.

If you wish to make comments regarding this document, please send them to public-web-nfc@w3.org (subscribe, archives).

Table of Contents

1. 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, and SHOULD are to be interpreted as described in [RFC2119].

This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces it contains.

Implementations that use ECMAScript to implement the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification and terminology.

2. Terminology

The EventHandler interface represents a callback used for event handlers as defined in [HTML5].

The concepts queue a task and fire a simple event are defined in [HTML5].

The terms event handler and event handler event types are defined in [HTML5].

Promise, and JSON.parse are defined in [ECMASCRIPT].

The algorithms utf-8 encode, and utf-8 decode are defined in [ENCODING].

EventInit, DOMException, AbortError, SyntaxError, NotSupportedError, NotFoundError, and SecurityError are defined in [DOM4].

The term web app refers to a Web application, i.e. an application implemented using Web technologies, and executing within the context of a Web user agent, e.g. a Web browser or other Web-based runtime environments.

The term expressed permission refers to an act by the user, e.g. via user interface or host device platform features, via which the user approves the permission of a web app to access the Web NFC API.

The term obtain permission for a certain operation refers to obtain expressed permission or to ensure the existence of a prearranged trust relationship.

URL is defined in [URL].

Blob is defined in [FILEAPI].

DOMString, ArrayBuffer, BufferSource and any are defined in [WEBIDL].

NFC stands for Near Field Communications, short-range wireless technology operating at 13.56 MHz which enables communication between devices at a distance less than 10 cm. The NFC communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards, including ISO/IEC 14443 and FeliCa. The NFC standards include ISO/IEC 18092[5] and those defined by the NFC Forum. See http://www.nfc-forum.org/specs/spec_list/ for a complete listing.

An NFC adapter is the software entity in the underlying platform which provides access to NFC functionality implemented in a given hardware element (NFC chip). A device may have multiple NFC adapters, for instance a built-in one, and one attached via USB.

An NFC tag is a passive, unpowered NFC device. The NFC tag is powered by magnetic induction when an active NFC device is in proximity range. An NFC tag contains a single NDEF message.


The way of reading the message may happen through proprietary technologies, which require the reader and the tag to be of the same manufacturer. Implementations are expected to encapsulate this.

An NFC peer is another device, which can interact with other devices in order to exchange data using NFC.

An NDEF message encapsulates one or more application-defined NDEF records. NDEF stands for NFC Forum Data Exchange Format, a lightweight binary message format. NDEF messages can be stored on a NFC tag or exchanged between NFC-enabled devices.

An NDEF record has a maximum payload of 2^32-1 bytes. The record also contains information about the payload size, type, and an optional identifier. NFC Forum standardized a small set of useful data types to be used in NDEF records, for instance text, URL, media. In addition, there are record types designed for more complex interactions, such as Smart Poster, and handover records.

Part of the NDEF record is the TNF field, standing for Type Name Format. It can take binary values representing the following types:

TNF value NDEF record type
0 Empty
1 NFC Forum Well-Known Type
2 Media Type
3 Absolute URI
4 NFC Forum External Type
5 Unknown
6 Unchanged
7 Reserved

NFC Forum Well-Known Type includes record types text, URI, Smart Poster (containing a URI or other data and possible actions).

A Web NFC message is an NDEF message which contains at least one Web NFC record.

A Web NFC record is an NDEF record with TNF=4 (External Type Record), and the type field set to "urn:nfc:ext:w3.org:webnfc". Further formatting details are described Data Types.

An NFC handover defines NFC Forum Well Known Types and the corresponding message structure that allows negotiation and activation of an alternative communication carrier, such as Bluetooth or WiFi. The negotiated communication carrier would then be used (separately) to perform certain activities between the two devices, such as sending photos to the other device, printing to a Bluetooth printer or streaming video to a television set.

The term sufficient permission in this document means that a web app which is invoking the methods of this API has been checked to comply with the security policies set by the underlying platform and API implementation in the moment and context of invoking the API method. Further details are described in Security and Privacy.

The term document base URL is defined in [HTML5].

The term URL scope is introduced in this document for NFC operations as a sub-domain match to the web app's document URL, which includes the domain of the calling web app.

3. Introduction

This section is non-normative.

There are three groups of user scenarios for NFC:

NFC works using magnetic induction, meaning that the reader will emit a small electric charge which then creates a magnetic field. This field powers the passive device which turns it into electrical impulses to communicate data. Thus, when the devices are within range, a read is always performed (see NFC Analog Specification and NFC Digital Protocol, NFC Forum, 2006). The peer-to-peer connection works in a similar way, as the device periodically switches into a so-called initiator mode in order to scan for targets, then later to fall back into target mode. If a target is found, the data is read the same way as for tags.

As NFC is based on existing RFID standards, many NFC chipsets support reading RFIDs tags, but many of these are only supported by single vendors and not part of the NFC standards. Though certain devices support reading and writing to these, it is not a goal of this specification to support proprietary tags or support interoperability with legacy systems.

The NFC Forum has mandated the support of four different tag types to be operable with NFC devices. The same is required on operating systems such as Android.

  1. NFC Forum Type 1: This tag is based on the ISO/IEC 14443-3A (also known as NFC-A, as defined in ISO/IEC 14443-3:2011, Part 3: Initialization and anticollision). The tags are rewritable and can be configured to become read-only. Memory size can be between 96 bytes and 2 Kbytes. Communication speed is 106 kbit/sec.
  2. NFC Forum Type 2: This tag is also based on the ISO/IEC 14443-3A (NFC-A). The tags are rewritable and can be configured to become read-only. Memory size can be between 48 bytes and 2 Kbytes. Communication speed is 106 kbit/sec. In contrast to Type 1, Type 2 has anti-collision protection for dealing with multiple tags within the NFC field.
  3. NFC Forum Type 3: This tag is based on the Japanese Industrial Standard (JIS) X 6319-4, commonly known as FeliCa. The tags are preconfigured to be either rewritable or read-only. Memory availability is variable, theoretical memory limit is 1MByte per service. Communication speed is 106 kbit/sec. Like Type 2, it supports anti-collision protection.
  4. NFC Forum Type 4 (November 2010): This tag is based on the ISO/IEC 14443 like Type 1 and 2, but it support either NFC-A or NFC-B for communication. On top of that the tag may support the Data Exchange Protocol (aka ISO-DEP) defined in ISO/IEC 14443 (ISO/IEC 14443-4:2008 Part 4: Transmission protocol). Like Type 3, the tags are preconfigured to be either rewritable or read-only. Variable memory, up to 32 KB per service. Supports three different communication speeds 106 or 212 or 424 Kbits/s.

In addition to data types standardized for NDEF records by the NFC Forum, many commercial products, e.g. bus cards, door openers etc, use different card specific data and protocol extensions which require specific NFC chips (same vendor of card and reader) in order to work.

Card emulation mode capabilities also depend on the NFC chip in the device. For payments, a Secure Element is often needed.

3.1 Use Cases

This section is non-normative.

A few Web NFC user scenarios are described in this document. These user scenarios can be grouped along criteria based on security, privacy and feature categories, resulting in generic flows as follows.

3.1.1 Reading NFC tags

  1. Reading arbitrary tags when no web site is open: when the user touches a device to an NFC tag when no web site is currently open, the user agent can open a website to handle that tag. If multiple websites can handle the tag, a choice is presented to the user to pick the preferred web site for handling the tag. Optionally, web sites have a programmatic means to tell the user agent they are able and interested to handle NFC tags of certain type.
  2. Reading arbitrary tags when a website is currently open: if the user has a website open and that website has indicated that it's able to read a set of tags, it might be fine to allow that website to read a read-only tag that the user taps without presenting any permission or security dialog to the user.

3.1.2 Writing NFC tags

  1. Writing to arbitrary writable tags: the user opens a web page which can write an NFC tag. This use case SHOULD be restricted or bound to user permissions for security and privacy reasons.
  2. Writing to NFC tags already containing a Web NFC message: the user agents MAY allow web sites to write to the tag with using appropriate security dialogs.

3.1.3 Sending data to NFC peers

In general, sending data to another Web NFC capable device requires that on the initiating device the user would first have to navigate to a web site. The user would then touch the device against another Web NFC equipped device, and data transfer would occur. On the receiving device the user agent will dispatch the content to a web site registered to handle the content and in case of multiple such web sites, the one chosen by the second user.

3.1.4 Handover to another wireless connection type

NFC supports handover protocols to Bluetooth or WiFi connectivity for the purpose of larger volume data transfer. The user touches another NFC capable device, and as a result configuration data is sent for a new Bluetooth or WiFi connection, which is then established between the devices.

3.2 Features

High level features for the Web NFC specification include the following:

  1. Support devices with single or multiple NFC adapters.
  2. Support communication with active (powered devices such as readers, phones) and passive (smart cards, tags, etc) devices.
  3. Allow users to act on (e.g. read, write or transceive) discovered NFC devices (passive and active) as well as access the NDEF records which were read in the process.
  4. Allow the user to write a payload via NDEF records to compatible devices, such as writeable tags, when they come in range.
  5. [future] Allow manual connection for various technologies such as NFC-A and NFC-F depending on secondary device.
  6. [future] Allow NFC handover to Bluetooth or WiFi.
  7. [future] Allow card emulation with secure element or host card emulation.

NFC is usually deeply integrated into device platforms (e.g. Android, Windows, etc), because end-to-end user experience implications (e.g. users need to be presented platform specific dialogs for selecting applications and actions). Also, privacy and security related issues require platform specific solutions.

The various integrated technologies, wide variety of use cases, and platform integration issues make standardization of NFC for the web a challenge. Therefore this specification makes a few simplifications in what use cases and data types are possible to handle by users of this API:

3.3 Technical requirements

The following high level technical requirements result from the enumerated use cases and high level features. With this version of the API, web pages should be able to:

  1. Request an NFC adapter. If there are multiple adapters present, then the user agent MAY display a dialog for selecting one of them.
  2. Get notified about NDEF message available from tag or peer device.
  3. Set a data payload that the user can push or write to another device when within range.

4. Security and Privacy

The Permissions API SHOULD be supported by user agents for implementing NFC related [permissions]. The required permission name is "nfc".

User agents MUST NOT provide Web NFC API access to web apps without the expressed permission of the user. User agents must acquire consent for [permissions] for each call to the methods of this API, unless a prearranged trust relationship applies.


Considering adding the following: User agents MUST implement the WebNFC API to be HTTPS-only. SSL-only support provides better protection for the user against man-in-the-middle attacks intended to obtain push registration data. Browsers may ignore this rule for development purposes only.

Permissions that are preserved beyond the current browsing session MUST be revocable.


The Permissions API does not yet address the issue of revoking permissions. When it will be addressed, this section will be updated.

User agents MUST implement the following policies:

  1. In order to use NFC, a website MUST be visible and in focus. For web pages in background, receiving and sending NFC data MUST be suspended.
  2. Writing to an NFC tag, including locking the tag to read-only MUST always obtain permission.
  3. Sending data to an NFC peer MUST always obtain permission.
  4. Listening to NDEF messages MUST always obtain permission.
  5. In addition to the previous, only websites with a schema starting with "https://" SHOULD be able to read NFC tags that is not empty or does not contain a Web NFC messages.

5. Data Types

Web NFC implementations SHOULD use Web NFC messages, which SHOULD be sufficiently differentiated in order to avoid accidental matching with a generic NDEF message used in regular NFC tags or between NFC peers. This is achieved by using an additional Web NFC record, and in rest using normal NDEF records in order to compose the NDEF message.

5.1 The format of a Web NFC record

The format of a Web NFC record is the following.

5.2 Web NFC message payload

The payload of a Web NFC message is represented by using normal NDEF records. The following types can be used as payload, i.e. when writing to NFC tags, sending data to NFC peers, and when reading NDEF messages.

typedef (DOMString or URL or Blob or JSON) NfcData;

NfcData denotes the data types supported as NDEF record payload in read and send operations in this API.

The mapping from supported NfcData to NDEF record types, as used in the send() method is as follows:

NfcData NDEF record type
DOMString NFC Forum Well Known Type (TNF=1) with type Text
  • NFC Forum Well Known Type (TNF=1) with type URI
  • NFC Forum Well Known Type (TNF=1) with type Smart Poster
  • Absolute URI as defined in [RFC3986] (TNF=3)
JSON Media-type as defined in [RFC2046] (TNF=2) with associated MIME type "application/json"
Blob with MIME type Media-type as defined in [RFC2046] (TNF=2)
Blob without MIME type NFC Forum External Type (TNF=4)

The mapping from NDEF record types to NfcData, as used for incoming NDEF messages exposed by the NfcMessageEvent, is as follows:

NDEF record type NfcData
NFC Forum Well Known Type (TNF=1) with type Text DOMString
NFC Forum Well Known Type (TNF=1) with type URI URL object
NFC Forum Well Known Type (TNF=1) with type Smart Poster URL object
Absolute URI as defined in [RFC3986] (TNF=3) URL object
Media-type as defined in [RFC2046] (TNF=2) with associated MIME type "application/json" JSON object
Media-type as defined in [RFC2046] (TNF=2) Blob object
NFC Forum External Type (TNF=4) with type other than urn:nfc:ext:w3.org:webnfc Blob object
Any other NDEF record type Blob object

Note that Web NFC records are not exposed to client web apps.

6. Extensions to the Navigator interface

The HTML specification defines a Navigator interface [HTML] which this specification extends.

partial interface Navigator {
    readonly    attribute Nfc nfc;

6.1 The nfc attribute

When getting the nfc attribute, the user agent MUST return the Nfc object, which provides NFC related functionality.

7. The Nfc interface

interface Nfc {
    Promise<NfcAdapter> requestAdapter ();

Implementations MAY expose multiple NFC adapters. By using the requestAdapter() method, web apps can obtain an adapter object providing NFC functionality. When this method is invoked, the user agent MUST run the following steps:

  1. Let promise be a new Promise object.
  2. Return promise and continue the following steps asynchronously.
  3. If sufficient permission has not been granted to use this method, that is, to use NFC technology from the calling web app, then reject promise with "SecurityError", and terminate these steps.
  4. If there is no support for NFC adapter handling functionality in hardware, software, or due to physical incompatibility, then reject promise with "NotSupportedError", and terminate these steps.
  5. Make a request to the underlying platform to initialize NFC functionality and enumerate available adapters. If the request fails, then reject promise with "NotSupportedError", and terminate these steps.
  6. If the request is successful, then select one of the adapters based on the following algorithm:
    1. Let adapter be null.
    2. If there is only one adapter, set adapter to that.
    3. If there are multiple adapters available, and there is a system or user setting available with a default adapter being specified, set adapter to that.
    4. Otherwise, the user agent MAY pop up a user dialog for selecting one of the listed adapters, or none of them, and set adapter to the selected one, if available.
    5. If no adapter is selected, then reject promise with "NotFoundError", and terminate these steps.
    6. Otherwise if the dialog is blocked or canceled, then select the first built-in adapter.
    7. Otherwise select the first external (e.g. USB) adapter.
  7. Resolve promise with adapter.

8. The NfcAdapter interface

interface NfcAdapter : EventHandler {
                attribute EventHandler onmessage;
    Promise<void> send (NfcMessage message, optional NfcSendOptions options);

The NfcAdapter interface handles incoming NDEF messages, exposed by the NfcMessageEvent event, either from an NFC tag or an NFC peer. By default, listening to this event SHOULD be disabled.

8.1 Events used with the NfcAdapter interface

The following are the event handlers implemented by the NfcAdapter interface.

event handler event name event type
onmessage message NfcMessageEvent

8.1.1 The message event

The message event is used for notifying the adapter object about an NDEF message dispatched to the web app.

8.1.2 The NfcMessageEvent interface

In this specification, NDEF message content is delivered by an NfcMessageEvent event.

interface NfcMessageEvent : Event {
    readonly    attribute NfcMessage message;

The message property MUST return the NfcMessage representing the payload data of the NDEF message.

8.1.3 The NfcMessage interface

The content of the NDEF message is exposed by the following interface:

interface NfcMessage {
    readonly    attribute USVString     scope;
    readonly    attribute sequence<any> data;
    // (DOMString or URL or Blob or JSON)

The scope property MUST return the URL scope which has written the message.

The data property MUST return the payload data of the NDEF message as an array of either DOMString, or URL object, or Blob object, or serializable JSON object as a generic Object.

8.2 The send() method

The send() method is used for sending an NDEF message to either an NFC tag for writing, or to an NFC peer device, next time when they get into proximity range. When this method is invoked, the user agent MUST run the following steps:

  1. Let promise be a new Promise object.
  2. Return promise and continue the following steps asynchronously.
  3. If sufficient permission has not been granted to use this method, then reject promise with "SecurityError", and terminate these steps.
  4. If there is no support for the functionality of sending data to an NFC peer in proximity range, or to write data to an NFC tag, then reject promise with "NotSupportedError", and terminate these steps.
  5. Parse the argument options. If it is undefined or null, then use the default values. Otherwise if invalid, then reject promise with "SyntaxError", and terminate these steps.
  6. Parse the argument message.scope. If the value is undefined, then set scope to the DOMString describing the document base URL. If it is invalid in the given platform, or if it is not a sub-domain match of the document base URL, then reject promise with "SyntaxError", and terminate these steps.
  7. For each element in the array message.data, check the type to be one of the supported types. If the value is invalid on the given platform, then reject promise with "SyntaxError", and terminate these steps. For each valid element create an NDEF record. The implementation choose the best suitable NDEF record format for the given platform. Each element in the input array given in message.data SHOULD map to a separate NDEF record in the NDEF message to be sent.
  8. Assemble an NDEF message from the NDEF records and an additional Web NFC record, referred to as output.
  9. Make a request to the underlying platform to send output to the next device which comes in proximity range.
  10. If options.target has the value "tag", then the sending should only happen if an NFC tag is tapped within a platform specific timeout, otherwise reject promise with a "TimeoutError" in the case of timeout, or "InvalidAccessError" if an NFC peer is tapped instead of a tag.
  11. If options.target has the value "peer", then the sending should only happen if an NFC peer is tapped within a platform specific timeout, otherwise reject promise with a "TimeoutError" in the case of timeout, or "InvalidAccessError" if an NFC tag is tapped instead of a peer.
  12. If options.target has the value "any" (which is the default value), then the sending should happen if either an NFC peer or an NFC tag is tapped within a platform specific timeout, otherwise reject promise with "TimeoutError".
  13. If the request is successful, then resolve promise.

8.2.1 The NfcSendOptions dictionary

enum NfcTarget {
dictionary NfcSendOptions {
             NfcTarget target;

The target property denotes the intended target for the pending send() operation. The default value is "any".

9. Examples

This section is non-normative.

This section shows how developers can make use of the various features of this specification.

Example 1: Check permissions for NFC
navigator.permissions.query({name: 'nfc'}).then((result) => {
    if (result.status == 'granted') {
      enableNfcUseCase();  // Do things here.
    } else if (result.status == 'prompt') {
      // The user agent will prompt.
    // Otherwise don't do anything since it will fail.
Example 2: Read and write tag
var adapter = null;
navigator.nfc.requestAdapter().then((nfcAdapter) => {
  adapter = nfcAdapter;
  adapter.onmessage = onMessage;

function onMessage(event) {
  console.log("NDEF message received from scope " + event.message.scope);
  var data = event.message.data;

  if (!data) { // empty tag
    writeMessageOnTag({data: Initializing a passive tag”});

  if (typeof data == string’) {
    console.log(“Data is string:  + data);
  } else if (data instanceof Blob) {
  } else if (data instanceof URL) {
    console.log(“Data is URL:  + data.toString());
  } else if (typeof data == object’) {

function writeMessageOnTag(msg) {
    adapter.send(msg, {target: "tag"})
      .then(() => { console.log("Send was successful")})
      .catch(() => { console.log("Send failed")});

function processBlob(data) {
    console.log(“Blob size:  + data.size +  bytes”);
    console.log(“Blob type:  + data.type);
    var reader = new FileReader();
    reader.addEventListener(“loadend”, function() {
      console.log(“Blob data:  + reader.result);
      // Now send a response based on the data.
      adapter.send({data: Response to blob })
        .then(() => { console.log("Send was successful")})
        .catch(() => { console.log("Send failed")});

function processJson(data) {
  if (myCondition(data.myKnownProperty)) {
    adapter.send({data: Custom data”});
Example 3: Save and restore game progress with another device
navigator.nfc.requestAdapter().then((adapter) => {
  console.log("Waiting for game state");
  adapter.onmessage = (event) => {
    console.log("Game state received from: " + event.message.scope);
    console.log("Game state: " + event.message.data);
    // Now do some calculations and update the state.
    adapter.send({ scope: event.message.scope,
                   data: [ { level: 3, points: 4500, lives: 3 } ] })
      .then(() => { console.log("Send was successful")})
      .catch(() => { console.log("Send failed")});

A. Changes

The following is a list of substantial changes to the document. For a complete list of changes, see the change log on Github. You can also view the recently closed bugs.

B. Open issues

The following problems are being discussed and need most attention:

C. Acknowledgements

The editors would like to express their gratitude to the former editors Luc Yriarte and Samuel Ortiz, and also to Don Coleman, Jeffrey Yasskin, Salvatore Iovene, and Alexander Shalamov for their technical guidance, implementation feedback and support.

D. References

D.1 Normative references

Anne van Kesteren; Aryeh Gregor; Ms2ger; Alex Russell; Robin Berjon. W3C DOM4. 28 April 2015. W3C Last Call Working Draft. URL: http://www.w3.org/TR/dom/
Allen Wirfs-Brock. ECMAScript 2015 Language Specification. Draft. URL: https://people.mozilla.org/~jorendorff/es6-draft.html
Anne van Kesteren; Joshua Bell; Addison Phillips. Encoding. 16 September 2014. W3C Candidate Recommendation. URL: http://www.w3.org/TR/encoding/
Arun Ranganathan; Jonas Sicking. File API. 21 April 2015. W3C Working Draft. URL: http://www.w3.org/TR/FileAPI/
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
Anne van Kesteren; Sam Ruby. URL. 9 December 2014. W3C Working Draft. URL: http://www.w3.org/TR/url-1/
Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/WebIDL/

D.2 Informative references

N. Freed; N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
S. Josefsson. The Base16, Base32, and Base64 Data Encodings. October 2006. Proposed Standard. URL: https://tools.ietf.org/html/rfc4648
Mounir Lamouri; Marcos Caceres. The Permissions API. 7 April 2015. W3C Working Draft. URL: http://www.w3.org/TR/permissions/