IEC 63652-2:2026

IEC 63652-2 ®
Edition 1.0 2026-02
INTERNATIONAL
STANDARD
NFC Forum Specifications -
Part 2: NFC Data Exchange Format
ICS 33.160.60  ISBN 978-2-8327-1007-4

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a
publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.

Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
NFC Forum Specifications -
Part 2: NFC Data Exchange Format
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national
electrotechnical committees (IEC National Committees). The object of IEC is to promote international co -operation on all
questions concerning standardization in the electrical and electronic fields. To this end and i n addition to other activities, IEC
publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS)
and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any
IEC National Committee interested in the subject dealt with may participate in this preparatory work. International,
governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC
collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC
National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any
end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC
Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried
out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its
technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature
whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use
of, or reliance upon, this IEC Publication or any other IEC Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). IEC
takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the
date of publication of this document, IEC had not received notice of (a) patent(s), which may be required to implement this
document. However, implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at https://patents.iec.ch. IEC shall not be held responsible for identifying any or all such
patent rights.
IEC 63652-2 has been prepared by technical area 15: Wireless Power Transfer, of IEC technical
committee 100: Audio, video and multimedia systems and equipment. It is an International
Standard.
It is based on NFC Data Exchange Format Version 1.0 and was submitted as a Fast-Track
document.
The text of this International Standard is based on the following documents:
Draft Report on voting
100/4400/FDIS 100/4435/RVD
Full information on the voting for its approval can be found in the report on voting indicated in the
above table.
The language used for the development of this International Standard is English.
The structure and editorial rules used in this publication reflect the practice of the organization
which submitted it.
This document was developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC
Directives, IEC Supplement, available at www.iec.ch/members_experts/refdocs. The main
document types developed by IEC are described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the specific
document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
NOTE In accordance with ISO/IEC Directives, Part 1, IEC PASs are automatically withdrawn after 4 years.

NFC Data Exchange Format
Technical Specification
Version 1.0
2021-08-23
[NDEF]
TM
NFC Forum
Contents
Contents
1 Overview. 1
1.1 Objectives . 1
1.1.1 Design Goals . 1
1.1.2 Anti-Goals . 2
1.2 Applicable Documents or References . 2
1.3 Administration . 3
1.4 Trademark and Logo Usage . 3
1.5 Intellectual Property . 3
1.6 Special Word Usage . 3
1.7 Abbreviations . 3
1.8 Glossary. 4
2 NDEF Mechanisms . 6
2.1 Introduction . 6
2.2 Intended Usage . 6
2.3 NDEF Encapsulation Constructs . 7
2.3.1 NDEF Message . 7
2.3.2 NDEF Record . 8
2.3.3 NDEF Record Chunks . 8
2.4 NDEF Payload Description . 11
2.4.1 NDEF Payload Length . 11
2.4.2 NDEF Payload Type . 11
2.4.3 Payload Identification . 13
2.5 Data Transmission Order. 13
2.6 NDEF Record Layout . 14
2.6.2 MB (Message Begin) . 14
2.6.3 ME (Message End) . 14
2.6.4 CF (Chunk Flag) . 15
2.6.5 SR (Short Record) . 15
2.6.6 IL (ID_LENGTH Field is Present) . 15
2.6.7 TNF (Type Name Format) . 16
2.6.8 TYPE_LENGTH . 18
2.6.9 ID_LENGTH . 18
2.6.10 PAYLOAD_LENGTH . 18
2.6.11 TYPE . 18
2.6.12 ID . 19
2.6.13 PAYLOAD . 19
3 Special considerations . 20
3.1 Internationalization . 20
3.2 Security . 20
3.3 Maximum Field Sizes . 20
3.4 Use of URIs in NDEF . 20
A. Exhibit A . 22
B. Revision History . 23

NFC Data Exchange Format Page ii

Figures
Figures
Figure 1. Example of an NDEF Message with a Set of NDEF Records . 7
Figure 2. NDEF Octet Ordering . 13
Figure 3. NDEF Record Layout . 14
Figure 4. NDEF Short Record Layout (SR=1) . 15

Tables
Table 1: Abbreviations . 4
Table 2. TNF Field Values . 16
Table 3: Revision History . 23

Requirements
Requirements 1: Intended Usage . 7
Requirements 2: NDEF Encapsulation - Message . 8
Requirements 3: NDEF Encapsulation – NDEF Record Chunks . 10
Requirements 4: NDEF Payload Length . 11
Requirements 5: NDEF Payload Type . 12
Requirements 6: Data Transmission Order . 13
Requirements 7: Normal Record Layout . 14
Requirements 8: SR (Short Record) . 15
Requirements 9: IL (ID_LENGTH Field is Present) . 16
Requirements 10: TNF (Type Name Format) . 17
Requirements 11: ID_LENGTH . 18
Requirements 12: PAYLOAD_LENGTH . 18
Requirements 13: TYPE . 19
Requirements 14: ID . 19
Requirements 15: Maximum Field Sizes. 20
Requirements 16: Use of URIs . 21
NFC Data Exchange Format Page iii

Overview
1 Overview
The NFC Data Exchange Format (NDEF) specification defines a message encapsulation format to
exchange information between two NFC Forum Devices.
NDEF is a lightweight, binary message format that can be used to encapsulate one or more
application-defined payloads of arbitrary type and size into a single message construct. Each
payload is described by a type, a length, and an optional identifier.
Type identifiers can be URIs, MIME media types, or NFC-specific types. This latter format
permits compact identification of well known types commonly used in NFC Forum applications,
or self-allocation of a name space for organizations that wish to use it for their own NFC-specific
purposes.
The NDEF Payload Length is an unsigned integer that indicates the number of octets in the
payload. A compact, NDEF short-record layout is provided for very small payloads.
The optional NDEF Payload Identifier enables association of multiple payloads and cross-
referencing between them.
NDEF Payloads can include nested NDEF Messages or chains of linked chunks of length
unknown at the time the data is generated.
NDEF is strictly a message format, which provides no concept of a connection or of a logical
circuit, nor does it address head-of-line problems.
1.1 Objectives
The NFC Data Exchange Format (NDEF) specification is a common data format for NFC Forum
Devices.
The NFC Data Exchange Format specification defines the NDEF data structure format as well as
rules to construct a valid NDEF Message as an ordered and unbroken collection of NDEF
Records. Furthermore, it defines the mechanism for specifying the types of application data
encapsulated in NDEF Records.
The NDEF specification defines only the data structure format to exchange application or service
specific data in an interoperable way, and it does not define any NDEF Record Types in detail —
NDEF Record Types are defined in separate specifications.
This NDEF specification assumes a reliable underlying protocol and therefore this specification
does not specify the data exchange between two NFC Forum Devices.
An NFC Forum Device can process the NDEF information independently of the way it has
received the NDEF Message.
Because of the large number of existing message encapsulation formats, record marking
protocols, and multiplexing protocols, it is best to be explicit about the design goals of NDEF
and, in particular, about what is outside the scope of NDEF.
1.1.1 Design Goals
The design goal of NDEF is to provide an efficient and simple message format that can
accommodate the following:
1. Encapsulating arbitrary documents and entities, including encrypted data, XML documents,
XML fragments, image data like GIF and JPEG files, etc.
NFC Data Exchange Format Page 1

Overview
2. Encapsulating documents and entities initially of unknown size. This capability can be used to
encapsulate dynamically generated content or very large entities as a series of chunks.
3. Aggregating multiple documents and entities that are logically associated in some manner into
a single message. For example, NDEF can be used to encapsulate an NFC-specific message
and a set of attachments of standardized types referenced from that NFC-specific message.
4. Compact encapsulation of small payloads should be accommodated without introducing
unnecessary complexity to parsers.
To achieve efficiency and simplicity, the mechanisms provided by this specification have been
deliberately limited to serve these purposes. NDEF has not been designed as a general message
description or document format such as MIME or XML. Instead, NFC applications can take
advantage of such formats by encapsulating them in NDEF Messages.
1.1.2 Anti-Goals
The following list identifies items outside the scope of NDEF:
1. NDEF does not make any assumptions about the types of payloads that are carried within
NDEF Messages or about the message exchange patterns implied by such messages.
2. NDEF does not in any way introduce the notion of a connection or a logical circuit (virtual or
otherwise).
3. NDEF does not attempt to deal with head-of-line blocking problems that might occur when
stream-oriented protocols like TCP are used.
1.2 Applicable Documents or References
[NFC RTD] NFC Record Type Definition (RTD) Specification, NFC Forum
[RFC 1700] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 1700,
October 1994.
[RFC 1900] B. Carpenter, Y. Rekhter, “Renumbering Needs Work”, RFC 1900, IAB,
February 1996.
[RFC 2046] N. Freed, N. Borenstein, “Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types” RFC 2046, Innosoft, First Virtual,
November 1996.
[RFC 2047] K. Moore, “MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text”, RFC 2047,
University of Tennessee, November 1996.
[RFC 2048] N. Freed, J. Klensin, J. Postel, “Multipurpose Internet Mail Extensions
(MIME) Part Four: Registration Procedures”, RFC 2048, Innosoft, MCI,
ISI, November 1996.
[RFC 2119] S. Bradner, “Key words for use in RFCs to Indicate Requirement
Levels”, RFC 2119, Harvard University, March 1997.
[RFC 2616] R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T. Berners-Lee,
“Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, U.C. Irvine,
DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997.
NFC Data Exchange Format Page 2

Overview
[RFC 2717] R. Petke, I. King, “Registration Procedures for URL Scheme Names”,
BCP: 35, RFC 2717, UUNET Technologies, Microsoft Corporation,
November 1999.
[RFC 2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, “Guidelines for new
URL Schemes”, RFC 2718, Xerox Corporation, Maxware, Pirsenteret,
WebTV Networks, Inc., UUNET Technologies, November 1999.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, “Format for Literal IPv6
Addresses in URL's”, RFC 2732, Nokia, IBM, AT&T, December 1999.
[RFC 3023] M. Murata, S. St. Laurent, D. Kohn, “XML Media Types” RFC 3023,
IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures,
January 2001.
[RFC 3986] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers
(URI): Generic Syntax”, RFC 3986, MIT/LCS, U.C. Irvine, Xerox
Corporation, January 2005.
[URI SCHEME] List of Uniform Resource Identifier (URI) schemes registered by IANA
is available at: http://www.iana.org/assignments/uri-schemes.
1.3 Administration
The NFC Forum NFC Data Exchange Format specification is an open specification supported by
the Near Field Communication Forum, Inc., located at:
401 Edgewater Place, Suite 600
Wakefield, MA, 01880
Tel.: +1 781-876-8955
Fax: +1 781-610-9864
http://www.nfc-forum.org/
1.4 Trademark and Logo Usage
The Near Field Communication Forum’s policy regarding the use of trademarks and logos is
described in the NFC Forum Brand Identity Guidelines and N-Mark Usage Guidelines, which can
be found on the NFC Forum website.
1.5 Intellectual Property
This document conforms to the Intellectual Property guidelines specified in the NFC Forum
Intellectual Property Rights Policy, as outlined in the NFC Forum Rules of Procedure. These
documents are available on the NFC Forum website.
1.6 Special Word Usage
The key words “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT” and “MAY” in this
document are to be interpreted as described in [RFC 2119].
1.7 Abbreviations
Table 1 contains the definitions of the abbreviations and acronyms used in this document.
NFC Data Exchange Format Page 3

Overview
Table 1: Abbreviations
Abbreviation Description
CF Chunk Flag
NDEF NFC Data Exchange Format
QoS Quality of Service
RFU Reserved for Future Use
URI Uniform Resource Identifier
1.8 Glossary
Big Endian
A method of recording or transmitting numerical data of more than one byte, with the
most significant byte placed at the beginning.
Chunked Payload
Application data that has been partitioned into multiple chunks, each carried in a separate
NDEF Record.
NDEF Application
The logical, higher-layer application on an NFC Forum Device using NDEF to format
information for exchange with other NFC Forum Devices.
NDEF Generator
An entity or module that encapsulates application-defined payloads within NDEF
Messages.
NDEF Message
The basic message construct defined by this specification. An NDEF Message contains
one or more NDEF Records.
NDEF Parser
An entity or module that parses NDEF Messages and hands off the payloads to an NDEF
Application.
NDEF Payload
The application data carried within an NDEF Record.
NDEF Payload Identifier
An optional Uniform Resource Identifier (URI) that can be used to identify a payload.
NDEF Payload Length
An unsigned integer that indicates the number of octets in the payload of a single NDEF
Record.
NDEF Payload Type
An identifier that indicates the type of the payload.
NFC Data Exchange Format Page 4

Overview
NDEF Record
An NDEF Record contains a payload described by a type, a length, and an optional
identifier.
NDEF Record Chunk
An NDEF Record that contains a chunk of a payload rather than a full payload.
NDEF Short Record
An NDEF Record that allows payloads or chunks of up to 255 bytes to be carried.
NFC Forum Device
A device that supports at least one communication protocol for at least one
communication mode defined by the NFC Forum specifications. Currently the following
NFC Forum Devices are defined:
NFC Universal Device, NFC Tag Device and NFC Reader Device.
NFC Reader Device
An NFC Forum Device that supports the following Modus Operandi: Reader/Writer. It
can also support Initiator.
NFC Tag Device
An NFC Forum Device that supports at least one communication protocol for Card
Emulator and NDEF.
NFC Universal Device
An NFC Forum Device that supports the following Modus Operandi: Initiator, Target,
and Reader/Writer. It can also support Card Emulator.
NFC Data Exchange Format Page 5

NDEF Mechanisms
2 NDEF Mechanisms
This section describes the mechanisms used in NDEF. The specific syntax for these mechanisms
is defined in Section 3.
2.1 Introduction
NFC Forum Data Exchange Format is a lightweight binary message format designed to
encapsulate one or more application-defined payloads into a single message construct. An NDEF
Message contains one or more NDEF Records, each carrying a payload of arbitrary type and up
to 232-1 octets in size. NDEF Records can be chained together to support larger payloads. An
NDEF Record carries three parameters for describing its payload: the NDEF Payload Length, the
NDEF Payload Type, and an optional NDEF Payload Identifier. The purpose of these parameters
is as follows:
NDEF Payload Length
The NDEF Payload Length indicates the number of octets in the payload (see Section
2.4.1). Providing the NDEF Payload Length within the first 8 octets of an NDEF Record
makes efficient record boundary detection possible.
NDEF Payload Type
The NDEF Payload Type identifier indicates the type of the payload. NDEF supports
Uniform Resource Identifiers (URIs) [RFC 3986], MIME media type constructs [RFC
2046], and an NFC-specific type format as type identifiers (see Section 2.4.2). The
indication of the type of the payload makes it possible to dispatch the payload to the
appropriate NDEF Application.
NDEF Payload Identifier
A payload can be given an optional identifier in the form of an absolute or relative URI
(see Section 2.4.3). The use of an identifier enables payloads that support URI linking
technologies to cross reference other payloads.
2.2 Intended Usage
The intended usage of NDEF is as follows: an NDEF Application is designed to encapsulate one
or more related documents into a single NDEF Message. For example, this can be an application-
specific message along with a set of attachments, each of standardized type. The NDEF Generator
encapsulates each document in NDEF Records as payload or Chunked Payload, indicating the
type and length of the payload along with an optional identifier. The NDEF Records are then put
together to form a single NDEF Message. The NDEF Message is transmitted via NFC to another
NFC Forum Device where it is received and parsed. The NDEF Parser deconstructs the NDEF
Message and hands the payloads to a (potentially different) NDEF Application. Each NDEF
Message has to be sent or received in its entirety.
NDEF Records can encapsulate documents of any type. It is possible to carry MIME messages in
NDEF Records by using a media type such as “message/rfc822”. An NDEF Message can be
encapsulated in an NDEF Record by using an NFC-specific predefined type (see [NFC RTD]).
It is important to note that although MIME entities are supported, there are no assumptions in
NDEF that a record payload is MIME; NDEF makes no assumption concerning the types of the
payloads carried in an NDEF Message. Said differently, an NDEF Parser need not inspect the
NDEF Record type nor peer inside an NDEF Record in order to parse the NDEF Message.
NFC Data Exchange Format Page 6

NDEF Mechanisms
NDEF provides no support for error handling. It is up to the NDEF Parser to determine the
implications of receiving a malformed NDEF Message or an NDEF Message containing a field
length beyond its processing capabilities. It is the responsibility of the NDEF Applications
involved to provide any additional functionality such as QoS that they need as part of the overall
system in which they participate.
Requirements 1: Intended Usage
NFC Forum Device
2.2.1.1 Each NDEF Message SHALL be sent or received in its entirety.

2.3 NDEF Encapsulation Constructs
2.3.1 NDEF Message
An NDEF Message is composed of one or more NDEF Records. The first NDEF Record in an
NDEF Message is marked with the MB (Message Begin) flag set and the last NDEF Record in
the NDEF Message is marked with the ME (Message End) flag set (see Sections 2.6.2 and 2.6.3).
The minimum NDEF Message length is one NDEF Record which is achieved by setting both the
MB and the ME flag in the same NDEF Record. Note that at least two record chunks are required
in orde
...