Direct answer

Understand NDEF message headers, TNF values, text and URI payloads, multi-record ordering, capacity overhead and safe NFC product design.

Why the NFC Forum created NDEF

NDEF gives otherwise different NFC tags and devices a shared envelope for exchanging application data. Product teams can specify the meaning of a tap at the record level instead of exposing users to a chip-specific page or block layout.

Interoperability goal
A valid NDEF message can move between supported tag types because the logical record format is separated from the physical memory mapping.
Scope boundary
NDEF does not add encryption or prove authenticity; those properties require a secure chip, protocol and verification design.

The anatomy of an NDEF message

An NDEF message contains one or more records. Each record carries a compact header, type-length information, an optional identifier and a payload, while message-begin and message-end bits mark the complete ordered set.

Message order
Readers process records in sequence, so put the primary user action before supporting metadata unless the receiving specification requires another order.
Empty message
A formatted blank tag can contain an empty NDEF message; blank, unformatted and unreadable are different states and should not share one error.

Header flags: MB, ME, CF, SR and IL

The first header byte packs message and payload rules into individual bits. MB and ME delimit the message, CF indicates a chunked record, SR selects a one-byte payload length, and IL announces that an ID-length field is present.

Short Record
SR saves bytes for payloads up to 255 bytes because the length occupies one byte instead of four, making it important on small Type 2 tags.
Chunking caution
Chunked payloads must preserve TNF and type rules across chunks; many consumer workflows are simpler and more compatible when one ordinary record fits.

TNF, Type, ID and Payload fields

The Type Name Format tells a parser how to interpret the Type field: NFC Forum well-known, MIME media, absolute URI, external type, unknown or unchanged for a continuation chunk. The optional ID identifies a record inside the message; it is not the tag UID.

Parser rule
Validate TNF and length combinations before decoding, because malformed headers can otherwise produce incorrect offsets or misleading content.
Naming rule
External types use a domain-based name controlled by the application owner, reducing collisions between proprietary record formats.

Text records and language encoding

A well-known Text record starts with a status byte that describes encoding and language-code length, followed by the language code and text. The payload is not just a raw UTF-8 string, so manual byte assembly must account for the prefix.

Localization
Store the correct IANA-style language code and use Unicode text so a receiving application can present the payload predictably.
Capacity planning
Long multilingual text is usually better hosted on a web page with a short URI on the tag, especially when the content changes.

URI records and prefix compression

A well-known URI record stores one prefix-code byte followed by the remaining URI characters. Common prefixes such as HTTPS can therefore consume less memory than writing the same address as an unstructured text payload.

Canonical destination
Use one durable HTTPS URL with redirects under your control rather than embedding temporary campaign parameters that make the tag expensive to replace.
Security display
The app should display the resolved scheme and host before opening an unfamiliar URI so a user can distinguish a legitimate destination from a look-alike.

MIME, external and Smart Poster records

MIME records label payloads with a media type, external records establish an application-owned namespace, and Smart Poster combines a URI with human-facing metadata. Choosing among them depends on who must read the tag and whether a web fallback is required.

Broadest reach
A simple HTTPS URI generally has the widest cross-device behavior, while custom external types are suitable for an installed application that owns the contract.
Do not hide semantics
If a proprietary record triggers an action, document its version and provide a safe failure state when another app or older build encounters it.

Multi-record messages and ordering

A tag can carry several records, but more records are not automatically more useful. Each additional header consumes bytes and each receiving application may choose which record it understands, ignores or treats as the primary action.

Product decision
Combine records only when they form one coherent interaction, such as a destination plus an application-specific hint, rather than using the tag as a miniature content database.
Test matrix
Read the finished message with the native Android behavior, NFCMagic and at least one independent reader to expose assumptions about ordering.

Calculating record overhead and tag capacity

The visible payload is only part of the stored message. Record headers, type bytes, language codes, URI prefix bytes and the tag's NDEF container all affect whether the final encoded bytes fit the writable area.

Measure encoded bytes
Capacity checks should serialize the exact NdefMessage and compare its byte-array length with the Ndef maxSize reported for the target.
Keep headroom
A dynamic web destination keeps the physical payload small and allows future content growth without replacing a near-capacity tag.

Malformed records and defensive decoding

Real tags may contain interrupted writes, incorrect lengths, invalid encodings or vendor data that is not NDEF. A reader must separate unsupported content from a transport failure and should never crash while rendering untrusted bytes.

Safe output
Limit displayed text length, escape markup, show a hexadecimal fallback and avoid automatically launching actions from data that has not been reviewed.
Recovery path
Preserve raw diagnostic information for an authorized user while offering a clear erase or reformat option only when the technology supports it.

Quick reference

Record choice Best fit Main trade-off
URI Public web destination Needs a durable trusted domain
Text Short offline instruction Consumes payload bytes quickly
MIME Known media contract Receiver must understand the media type
External type App-owned workflow Requires versioned proprietary handling

Related NFCMagic app screens

These screenshots connect this NDEF records explained guide to the related Android workflow in NFCMagic. They document interface states; radio behavior still requires a physical Android device and real tags.

NFCMagic Read screen decoding multiple NDEF records and showing tag capacity
Decoded records make the logical NDEF structure visible without confusing it with the tag's raw memory.
NFCMagic Write composer creating URI, text, Wi-Fi and contact NDEF records
The composer validates a complete multi-record payload before asking the user to present a physical tag.

Frequently asked questions

Can one NFC tag contain multiple NDEF records?

Yes. One NDEF message can contain an ordered sequence of records, subject to the target tag's usable capacity and receiver compatibility.

Is a tag UID stored inside NDEF?

Not normally. The UID belongs to the tag technology layer; an NDEF record ID is an optional field inside one logical record.

Why is the encoded message larger than the visible text?

Headers, type data, encoding metadata and the NDEF container add bytes around the visible payload.

Does NDEF protect confidential data?

No. Ordinary NDEF is a data format, not an encryption layer. Public tags should not contain secrets.

Primary technical sources

  1. NFC Forum specifications — Primary index for NDEF, record types and NFC Forum tag specifications.
  2. Android Developers: Advanced NFC — Official guidance for tag technologies, NDEF operations and foreground dispatch.
  3. Android Developers: Ndef API — API contract for capacity, writability, NDEF I/O and permanent read-only operations.