NDEF Format Explained Simply
Bring any properly encoded NFC tag near any recent smartphone: the link opens, the business card appears, the Wi-Fi connects.
This apparent magic relies on a subtle ingredient: NDEF, the common language spoken by all tags and all phones.
This article explains what lies inside this universal envelope, and then for the curious: the exact anatomy of a record, byte by byte, and the famous TLVs that wrap it in the NFC chip's memory.
NDEF, the Common Language of NFC
NDEF stands for NFC Data Exchange Format, the data exchange format defined by the NFC Forum, the organization that standardizes the technology.
Its role: to guarantee that content written on a tag can be understood by any reader, regardless of the manufacturer of the chip or phone.
NDEF is hardware-independent: whether the tag is Type 1, 2, 3, 4, or 5, the message it carries is written and read in the exact same way. That is why the same encoded link works just as well on an NTAG213 tag as it does on an ISO 15693 chip.
One Message, Multiple Records
NDEF content is organized like mail: an envelope (the message) containing one or more cards (the records).
Each record consists of three elements: a small header of a few bytes, a type announcing the nature of the content (a URL, text, a business card...), and the payload, which is the content itself.
A message can contain just a single record (the most common case: a URL), but nothing prevents you from slipping several into the same envelope: a URL along with a text record and an application record, etc. The phone reads the records in order, but most smartphones only interpret and execute the VERY FIRST record.
Important: If you place multiple records on a tag, always put the primary content in the first position, otherwise it will be completely ignored by the phone.
The Most Common Record Types
Here are the main types of content for an NFC tag:
- URL / URI: Opens a website.
- Text: Displays text.
- vCard: Adds a contact (name, phone, email, ...).
- Wi-Fi / Bluetooth: Connects to a network or device.
- MIME / Media: Carries raw files or data formats.
- External Type: Allows saving custom/specific data.
- AAR (Android): Launches an Android app or opens the Play Store (ignored by iPhones).
Note: Most specific actions (social networks, payments, custom links) actually rely on URL or MIME records.
Anatomy of a URL Record
NDEF was designed for chips where every byte counts, and its most elegant trick involves URLs: the most common prefixes are replaced by a single-byte code. Thus, the entire "https://www." fits into code 02. Concrete result: the full address https://www.wakdev.com takes up only fifteen bytes.
Let's break them down: four header bytes (D1 01 0B 55, announcing a single record, of type U for URI, with eleven bytes of content), followed by the famous 02 prefix code, and then the ten characters of wakdev.com. It is this compression that allows a small 64-byte chip to comfortably hold a short link, and an NTAG213 to store a URL of around 132 characters.
Now let's look at this header under a magnifying glass, as every bit plays a role.
The first byte of a record concentrates five flags and a 3-bit field. The flags: MB (Message Begin) marks the first record of the message, ME (Message End) the last, CF (Chunk Flag) signals chunked content (very rare on tags), SR (Short Record) indicates a short record whose length fits on a single byte, and IL (ID Length) announces the presence of an optional identifier.
The remaining three bits form the TNF (Type Name Format), the family to which the type belongs: for a URL, its value is 001, the value for well-known NFC Forum types (other values exist for MIME types or third-party defined types, but they don't concern us here).
Let's take our first byte D1, or 1101 0001 in binary: MB set to 1, ME set to 1 (the record is alone, it opens and closes the message), CF set to 0, SR set to 1 (short format), IL set to 0 (no identifier), and TNF set to 001 (well-known type).
Next comes the type length (01: a single character), the payload length (0B: eleven bytes, on a single byte thanks to the SR flag; a long record would write it on four bytes), and then the type itself: U (0x55), the letter announcing a URI.
The payload brings up the rear, and for a URL, it follows a disarmingly simple grammar: a first byte provides the prefix code (02 for https://www.), and the rest of the address is written character by character, one byte each, making up the ten bytes of wakdev.com.
Eleven bytes in total, exactly what the length specified. And in a multi-record message, only the first carries MB and only the last carries ME: that is how the reader knows where the envelope begins and ends.
TLVs: Wrapping the Message in Memory
One question remains: how is this message stored in the chip's raw memory?
On Type 1, 2, and 5 tags, the answer is TLV, for Tag-Length-Value: every piece of information stored in memory is preceded by a T byte that announces its nature and an L length. The NDEF message travels inside a Type 03 TLV; a Terminator TLV (FE) marks the end of useful data; and other types exist for housekeeping (00 for a null/padding byte, 01 and 02 to describe lock and reserved memory areas). The length L fits on one byte for up to 254 bytes of content; beyond that, it switches to long format (FF followed by two bytes), allowing messages of several kilobytes on larger chips.
At the top of the memory sits the Capability Container (CC), the 4-byte index presenting the tag to the reader: the magic byte E1, the format version (10), the capacity of the NDEF area expressed in multiples of eight bytes, and access rights. Let's put it all together on an NTAG213: the CC contains E1 10 12 00 (0x12, or 18, times 8: 144 bytes of NDEF area, with open read and write access), then user memory follows with 03 (an NDEF message is coming), 0F (fifteen bytes), the fifteen bytes of our wakdev.com URL, and FE (terminated). The entire housekeeping cost only three bytes around the message: that's the whole mechanism. Other families wrap things differently but in the same spirit: Type 3 describes its message in a 16-byte attribute block, and Type 4 stores it in actual files (a CC file and an NDEF file), accessed via APDU commands.
Writing NDEF Without Worrying About Bytes
Good news: you will never have to assemble these bytes yourself. With the NFC Tools application, all you have to do is select "Write", add one or more records (a URL to https://www.wakdev.com, a text record, etc.), and bring the tag close: the application handles composing the envelope, headers, TLVs, and Capability Container by the book, making the message readable by all compatible smartphones.
On the reading side, Android natively recognizes NDEF tags; on iPhone, automatic background reading works starting from iPhone XS and XR, and NFC Tools allows reading and writing starting from iPhone 7 on iOS 15.6 or later, by initiating the scan within the app.
Key Takeaways
NDEF is the universal envelope of NFC: a message, one or more typed records, a header where every bit has a function, and TLVs that store the whole thing in memory behind a four-byte index table.
It is what guarantees that a tag encoded today will be understood by tomorrow's phones, no matter what chip carries it. And because NFC Tools writes strictly standard NDEF, including TLVs and headers, your tags will work everywhere, from the very first try to the millionth tap.
