oSIST 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
• Public Enquiry End Date: 29-Sep-2026
• ICS: 33.160.60 - Multimedia systems and teleconferencing equipment
• Technical Committee: AVM - Audio, video and multimedia systems and equipment
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 04-Aug-2026
• Due Date: 22-Dec-2026
• Directive: 2014/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: prEN IEC 63652-2:2026 - NFC Forum Specifications - Part 2: NFC Data Exchange Format

oSIST prEN IEC 63652-2:2026 is a draft European Standard from CLC that carries the text of IEC 63652-2:2026 for the NFC Data Exchange Format (NDEF). It specifies how two NFC Forum Devices package and interpret application data in a lightweight binary message format, including message structure, payload typing, identifiers, chunking and byte order.

For engineers, quality teams and buyers, this is the document to use when you need interoperable NFC message encoding and parsing rather than a transport protocol or a connection model.

What does oSIST prEN IEC 63652-2:2026 specify?

oSIST prEN IEC 63652-2:2026 specifies NDEF as a message encapsulation format for exchanging information between two NFC Forum Devices. It covers how one message can carry one or more application-defined payloads, each described by a type, a length and an optional identifier.

The scope is limited to the data format itself. NDEF is a message format, not a connection model, and it does not define logical circuits or head-of-line handling.

The document is organized into the following main parts:

• Clause 1 - Overview
• Clause 2 - NDEF Mechanisms
• Clause 3 - Special considerations
• Annex A - Exhibit A
• Annex B - Revision History

Annex	What it covers
A	Exhibit A
B	Revision history

What are the key requirements of oSIST prEN IEC 63652-2:2026?

oSIST prEN IEC 63652-2:2026 defines how to build and parse an NDEF Message, how to split large data into chunks, and how to represent payload length, type and identifiers. In practice, these rules tell implementers how to serialize records on the wire and how parsers should accept them.

Message boundaries and record order

Clause 2.3.1 and Requirement 2 state that an NDEF Message consists of one or more NDEF Records. The first record carries the MB (Message Begin) flag and the last record carries the ME (Message End) flag, and messages may not overlap.

That matters because a parser must use the serialized record order to reconstruct the message exactly as sent. Clause 2.3.1 also allows a full NDEF Message to appear as a payload inside another record, which is how nesting is done.

Chunking for large or generated payloads

Clause 2.3.3 and Requirement 3 define Chunked Payloads. A chunked payload is carried as an initial NDEF Record Chunk, zero or more middle chunks, and a terminating chunk, all within one NDEF Message.

Chunking is for reducing buffering needs and for carrying content whose full size is not known at generation time. It is not for multiplexing or streaming, so implementers should not use it to simulate parallel conversations.

Payload length and compact records

Clause 2.4.1 and Requirement 4 define PAYLOAD_LENGTH. Normal records use a four-octet unsigned length, while NDEF Short Records use a one-octet length for payloads up to 255 octets.

This matters for memory handling and parser design. A short record is a compact form for small payloads, but parsers are required to accept both normal and short layouts, including messages that mix them, as stated in Requirement 8.

Payload type and TNF

Clause 2.4.2 and Clause 2.6.7, together with Requirements 5 and 10, define how TYPE is interpreted through TNF (Type Name Format). The supported forms are NFC Forum Well Known Type, media-type, absolute URI, NFC Forum External Type, Unknown and Unchanged.

For implementers, this is the dispatch mechanism. The type of the first record is intended to provide processing context for the whole message, and the document expects registered media types and well-known URI schemes to be used where applicable.

Identifiers and field presence rules

Clause 2.4.3 and Requirement 14 define the optional NDEF Payload Identifier, which is a URI reference used for cross-referencing payloads. Clause 2.6.6, Clause 2.6.9 and Clause 2.6.10 define when ID_LENGTH, ID and PAYLOAD are present or omitted.

In practice, if you keep linked payloads after repackaging a message, you must preserve the identifier relationships. Middle and terminating chunks do not carry an ID field.

Byte order, size limits and parser tolerance

Requirement 6 states that multi-octet quantities are transmitted in Big Endian order. Requirement 15 says parsers shall not reject a message solely because SR is set, but they may reject records that exceed their design limits.

That is important for interoperability across constrained devices. A parser should accept the format first and then decide whether it can safely process the record contents.

URI handling and safety

Clause 3.4 and Requirement 16 give the URI guidance. The document advises avoiding IP addresses in URIs when possible, supporting literal IPv6 addresses when used, and relying on only the most basic URI equivalence rules.

Clause 3.2 also warns implementers to consider the security impact of record types that can trigger actions on the receiving device. In practice, the application should validate payload types before acting on them.

What terms does oSIST prEN IEC 63652-2:2026 define?

• NDEF Message - The basic message construct in NDEF, made up of one or more NDEF Records.
• NDEF Record - The unit that carries one payload, described by type, length and optional identifier.
• Chunked Payload - A payload split into multiple NDEF Record Chunks within one message.
• NDEF Short Record - A compact record format that uses a one-octet PAYLOAD_LENGTH field for payloads up to 255 octets.
• TNF (Type Name Format) - The 3-bit field that tells how the TYPE field is encoded and interpreted.
• NDEF Payload Identifier - An optional URI used to identify a payload and support cross-references.
• NFC Forum Device - A device that supports at least one NFC Forum communication protocol and communication mode.

Who uses oSIST prEN IEC 63652-2:2026?

oSIST prEN IEC 63652-2:2026 is used by teams that build, test or integrate NFC Forum Devices and their software stacks. That includes developers of NFC Reader Device, NFC Tag Device and NFC Universal Device products, plus application teams that exchange attachments, XML data, media types or nested NDEF Messages.

It is also relevant to interoperability labs, quality managers and buyers who need a common message format for NFC products. If a product must generate or parse NDEF consistently with other NFC Forum implementations, this is the specification to check.

Which standards are used with oSIST prEN IEC 63652-2:2026?

oSIST prEN IEC 63652-2:2026 cites these references for syntax, keyword meaning and type definitions.

Reference	What it contributes
NFC Record Type Definition (RTD) Specification [NFC RTD]	Defines NFC Forum Well Known Type and NFC Forum External Type formats
RFC 2119	Defines the meaning of SHALL, SHOULD and MAY
RFC 2046	Defines MIME media types and media-type syntax
RFC 2047	Gives MIME message header extensions for non-ASCII text
RFC 2048	Describes MIME registration procedures
RFC 2616	Provides HTTP/1.1 and the chunking analogy used in the document
RFC 2717	Covers registration procedures for URI scheme names
RFC 2718	Gives guidelines for new URI schemes and internationalization issues
RFC 2732	Defines literal IPv6 address format in URIs
RFC 3023	Defines XML media types
RFC 3986	Defines the generic syntax of Uniform Resource Identifiers (URI)
RFC 1700, RFC 1900	Provide assigned numbers context and advice on avoiding IP addresses in URIs

What does the oSIST prEN IEC 63652-2:2026 document contain?

oSIST prEN IEC 63652-2:2026 contains an overview, the NDEF mechanism definitions, and special considerations for internationalization, security, maximum field sizes and URI use. It also includes the abbreviations table and a glossary that define the main NDEF terms used throughout the specification.

The technical body includes the record layout figures, the short-record layout, the TNF value table and the requirements that govern message formation, chunking, field presence and parser behavior. Those are the parts implementers use when building generators, parsers and conformance tests.

Annex B adds the revision history, while Annex A is listed as Exhibit A.

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