prEN IEC 63652-2:2026

• Abstract:

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

• Status: Not Published
• Publication Date: 07-Nov-2028
• ICS: 33.160.60 - Multimedia systems and teleconferencing equipment
• Technical Committee: CLC/TC 100X - Audio, video and multimedia systems and equipment and related sub-systems
• Drafting Committee: CLC/TC 100X - Audio, video and multimedia systems and equipment and related sub-systems
• Current Stage: 4020 - Enquiry circulated - Enquiry
• Start Date: 31-Jul-2026
• Due Date: 04-May-2027
• Completion Date: 31-Jul-2026
• Directive: Harmonized Standard2014/53/EU - Directive 2014/53/EU of The European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC
• Mandate: M/536 - [C(2015)536] Standardisation request as regards radio equipment in support of Directive 2014/53/EU
• Mandate: M/607 - COMMISSION IMPLEMENTING DECISION of C(2025)1207 on a Standardisation Request M/607 as regards charging interface and charging communication protocol for radio equipment capable of being recharged by means of wireless charging in relation with Article 3(4), sixth subparagraph, of Directive 2014/53/EU of the European Parliament and of the Council.
• Ref Project: oSIST prEN IEC 63652-2:2026 - NFC Forum Specifications - Part 2: NFC Data Exchange Format

Overview

prEN IEC 63652-2:2026 defines the NFC Data Exchange Format (NDEF) - a standardized, lightweight, binary message encapsulation format for exchanging information between NFC Forum Devices. As a core part of the NFC Forum specifications, NDEF is designed to support interoperability across a wide range of NFC devices and services, facilitating seamless sharing of data in applications such as ticketing, retail payments, device pairing, and multimedia content delivery.

NDEF serves solely as a flexible message format, enabling encapsulation of one or more payloads - such as URLs, MIME types, or NFC-specific types - into a single unbroken message. Each payload is specified with its type, length, and optionally an identifier for association or referencing purposes. Notable features include support for short record layouts for small payloads, chunked records for larger or dynamically generated content, and nested or chained messages for complex data transmission.

Key Topics

• Binary Message Format: NDEF structures messages using a compact, binary encoding for efficient processing and minimal overhead, suitable for resource-constrained NFC devices.
• Payload Encapsulation: Each NDEF Message can encapsulate multiple payloads of arbitrary type and length, including encrypted files, XML documents, images, or plain text.
• Type Identification: Payload types are defined by standards-based identifiers such as URIs, MIME media types, or NFC-specific type formats, supporting flexible and extensible data exchange.
• Payload Length and Short Records: Payload length is indicated as an unsigned integer, with a special short-record layout provided for payloads up to 255 bytes to further reduce message size.
• Optional Identifiers: An optional identifier field allows for cross-referencing and logical association of multiple related payloads within a message.
• Chunked Records: Large or streaming payloads can be split into chunks, each carried in consecutive NDEF Records, facilitating transmission of data with initially unknown size.
• Strict Message Format: NDEF is concerned only with data encapsulation; it does not introduce connection management, logical circuits, streaming, or error handling at the transport level.

Applications

NDEF’s standardized format brings practical value by enabling:

• Smart Posters and Tags: Encode URLs, contact info, or promotions for simple tap-to-access experiences in advertising, product packaging, and public transit.
• Mobile Payments and Ticketing: Securely encapsulate transaction records or digital tickets for seamless NFC transactions at payment terminals or access gates.
• Device Pairing and Configuration: Exchange device-specific settings, authorization tokens, or service discovery data to enable rapid, user-friendly pairing and setup.
• Multimedia Sharing: Transfer files or media descriptors between phones, tablets, or kiosks with a simple tap, using well-defined media type identifiers.
• Secure Access Control: Bundle authentication tokens or certificates for physical or logical access, leveraging NDEF’s flexible payload support.
• IoT and Industry 4.0: Configure or monitor devices by exchanging parameter sets or commands via NFC tags or mobile interfaces.

By embracing NDEF as defined in prEN IEC 63652-2:2026, developers and integrators ensure broad compatibility and scalability for NFC-enabled solutions across consumer electronics, enterprise, and industrial environments.

Related Standards

• NFC Record Type Definition (RTD): Provides specific data type definitions utilized within NDEF payloads.
• NFC Forum Specifications - Part 1: Covers the overall architecture and requirements for NFC Forum devices.
• MIME (RFC 2046, RFC 2047, RFC 2048): Referenced for media type handling and message composition within NDEF records.
• Uniform Resource Identifier (URI) - RFC 3986: Basis for payload and identifier addressing in NDEF.
• ISO/IEC 14443, ISO/IEC 18092: NFC physical-layer and protocol standards upon which NDEF messages are commonly transported.
• Other Parts of IEC 63652 and NFC Forum Suite: For complete NFC system standardization, including protocols and compliance testing.

Adopting prEN IEC 63652-2:2026 ensures leading-edge interoperability, extensibility, and efficiency for any NFC data exchange implementation.

SLOVENSKI STANDARD
01-september-2026
Specifikacije NFC Foruma - 2. del: Oblika izmenjave podatkov NFC
NFC Forum Specifications - Part 2: NFC Data Exchange Format
NFC Forum Festlegungen - Teil 2: NFC Datenaustauschformat
Ta slovenski standard je istoveten z: prEN IEC 63652-2:2026
ICS:
33.160.60 Večpredstavni (multimedijski) Multimedia systems and
sistemi in oprema za teleconferencing equipment
telekonference
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
prEN IEC 63652-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2026
ICS 33.160.60 -
English Version
NFC Forum Specifications - Part 2: NFC Data Exchange Format
(IEC 63652-2:2026)
To be completed NFC Forum Festlegungen - Teil 2: NFC
(IEC 63652-2:2026) Datenaustauschformat
(IEC 63652-2:2026)
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2026-10-23.

The text of this draft consists of the text of IEC 63652-2:2026.

If this draft becomes a European Standard, CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CENELEC in three official versions (English, French, German).
A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to
the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 83780 Ref. No. prEN IEC 63652-2:2026 E

European foreword
This document (prEN IEC 63652-2:2026) consists of the text of document IEC 63652-2:2026, prepared
by IEC/TC 100 "Audio, video and multimedia systems and equipment".
This document is currently submitted to the Enquiry.
The following dates are proposed:
• latest date by which the existence of this document (doa) dav + 6 months
has to be announced at national level
• latest date by which this document has to be (dop) dav + 12 months
implemented at national level by publication of an
identical national standard or by endorsement
• latest date by which the national standards (dow) dav + 36 months
conflicting with this document have to be withdrawn (to be confirmed or
modified when voting)
This document has been prepared under a standardisation request addressed to CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.

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

IEC 63652-2:2026-02(en)
IEC 63652-2:2026 © IEC 2026
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
IEC 63652-2:2026 © IEC 2026
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.

IEC 63652-2:2026 © IEC 2026
NFC Data Exchange Format
Technical Specification
Version 1.0
2021-08-23
[NDEF]
TM
NFC Forum
IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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.: [phone]
Fax: [phone]
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

IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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

IEC 63652-2:2026 © IEC 2026
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
...