NDEF Explained: The Universal Format That Lets Any Phone Read Your Tag

What NDEF is — the one-paragraph answer

NDEF is the NFC Data Exchange Format, defined by the NFC Forum as the universal application-layer container for NFC tags. It sits on top of every NFC Forum tag type — NTAG, MIFARE Ultralight, FeliCa, ICODE — so the same encoded message reads identically on iPhone, Android, and a dedicated reader. Ever written a URL to a tag and watched it open on both platforms without extra work? That's NDEF doing its job. The radio layer settles the conversation; NDEF gives the bytes a shape. For the radio side, see how NFC actually works; for the broader context, NFC vs RFID and Bluetooth.

How an NDEF message is laid out

An NDEF message is one or more records concatenated together. Per the NFC Forum specification and the Android NdefMessage reference, the first record carries a Message Begin (MB) flag and the last carries a Message End (ME) flag. Most consumer tags hold a single-record message, though you can bundle several when needed.

Each record header carries a TNF (Type Name Format, 3 bits), control flags (MB, ME, CF, SR, IL), type and payload length fields, a short type string, an optional ID, and the payload itself.

The TNF cheat sheet:

A record's payload can theoretically reach 2^32 − 1 octets. In practice the chip caps you long before that — an NTAG213 ships with 144 bytes of user memory.

The record types you will actually meet

A few well-known types do almost all the work.

The URI record (TNF 0x01, type U) is by far the most common. Its Record Type Definition uses a one-byte prefix identifier to abbreviate the scheme — 0x04 for https://, 0x05 for tel:, 0x06 for mailto: — so the scheme isn't stored as literal text. Encoding https://nfcore.app costs one prefix byte plus eleven for nfcore.app: twelve bytes instead of nineteen. On a 144-byte tag, that matters.

The Text record (type T) carries UTF-8 plus a short language-code header. Smart Poster (type Sp) is itself a single NDEF record whose payload is a nested NDEF message: a URI sub-record plus optional Title (Text), Icon (MIME image), Action, and Size sub-records. The Smart Poster RTD is the format behind "tap to open the menu" tags; readers that don't understand it fall back to the inner URI. MIME records (TNF 0x02) carry typed payloads like image/png or application/vnd.bluetooth.ep.oob for Bluetooth handover. External type records (TNF 0x04) route to a specific vendor's app.

How phones decide what to do with the tap

Both platforms look at the first record's type to pick a handler. On Android, the NFC framework dispatches an ACTION_NDEF_DISCOVERED intent and matches it against registered intent filters; tags without NDEF fire ACTION_TAG_DISCOVERED instead. On iPhone XS and newer, Background Tag Reading parses NDEF automatically and routes a URL record to the default browser or to whichever app registered an Associated Domain for that host. Practical takeaway: put your most-specific record first. If you pair a URI with a Text record so a human can see the destination, the URI must come first or the OS won't auto-route the tap.

What NFCore shows you

NFCore's Write Data flow lets you build URL, Text, vCard, Wi-Fi, and custom NDEF records without touching hex. After the write, the Memory Dump view shows the bytes — byte index, hex, ASCII — so you can verify that the prefix compression and record layout match what you expected. The Command Console exposes raw page reads when you want to look at the NDEF TLV wrapper itself: the 0x03 length byte that opens an NDEF message, and the 0xFE terminator.

Frequently asked questions

Is NDEF the same on iPhone and Android?

Yes. NDEF is defined by the NFC Forum, and the same encoded message reads identically on iOS Core NFC and Android's android.nfc. The differences are in what each OS does with the parsed result, not in how the bytes are parsed.

What is the difference between an NDEF record and an NDEF message?

A message is the container; records are the items inside. An NDEF message is one or more concatenated records, with the first carrying a Message Begin flag and the last carrying a Message End flag.

Why does my URL record take fewer bytes than I expected?

The URI record uses a one-byte prefix identifier — 0x04 for https://, 0x05 for tel:, 0x06 for mailto: — so the scheme isn't stored as literal text. On a 144-byte NTAG213 that saves several bytes per record.

Do I need NDEF at all?

If your reader is your own custom app talking to your own tag, no. But every consumer phone and every default OS handler expects NDEF. Use it unless you have a specific reason not to.

Wrapping up

Once you have the message-and-record model in your head, the rest of the NFC ecosystem fits cleanly around it. NTAG capacity tells you what records fit; Smart Poster authoring becomes "a URI sub-record plus optional metadata." NDEF turns tag memory into something every phone can route — and once you can see the bytes in NFCore's Memory Dump, the format stops feeling like magic.