15 NFC Tags and NDEF Format
15.1 Start With the Story
An NFC tag is often treated like a tiny label, but the design problem is a record lifecycle. The tag has a family, memory size, write state, lock policy, payload format, validation rule, and fallback behavior.
Read this chapter as a release checklist for tag data. Plan the NDEF message, prove it fits, read it back, validate it before trusting it, and make clear what the tag does not authorize on its own.
15.2 Learning Objectives
By the end of this chapter, you should be able to:
- Review NFC tag family fit for simple NDEF records, file-style NDEF storage, vicinity-style labels, and application-specific credential behavior.
- Explain the relationship among tag memory, NDEF TLV containers, NDEF messages, record headers, record types, and payloads.
- Choose URI, Text, MIME, External, or composite record patterns for a practical IoT tag workflow.
- Validate capacity, write state, lock or protection behavior, parser output, application policy, fallback, and read-back evidence.
- Separate public NDEF payloads from secrets, credentials, private data, and authorization decisions.
15.3 Quick Check: NFC NDEF
15.4 Minimum Viable Understanding
- Tag type is not the payload. A tag family defines memory layout and commands; NDEF defines an interoperable payload format that may be stored on compatible tags.
- NDEF is structured input. A message contains records; each record has header flags, type information, optional ID, and a payload that the application still needs to validate.
- Capacity includes overhead. The usable payload must fit alongside TLV, record headers, type fields, language fields, terminator bytes, and any app-specific metadata.
- Write success is not release evidence. Read the tag back, decode the final NDEF, validate it in the target application, test fallback, and record retest triggers.
15.5 Tag Capability Review
Use tag-family names as review hints, not as proof that a tag fits the job.
15.5.1 Tag-Family Prompts
15.6 Tag Types and Discovery Path
NDEF is the data; the NFC Forum tag types are the chips that hold it, and they differ in memory, speed, and underlying technology.
| Tag type | Based on | Typical chip or use |
|---|---|---|
| Type 1 (T1T) | ISO 14443A | Topaz; simple, small tags |
| Type 2 (T2T) | ISO 14443A | MIFARE Ultralight or NTAG21x; common low-cost labels |
| Type 3 (T3T) | FeliCa (NFC-F) | Higher-memory labels and platform-specific deployments |
| Type 4 (T4T) | ISO 14443A/B plus ISO 7816-4 | DESFire-style file systems, larger data, and secured applets |
| Type 5 (T5T) | ISO 15693 (NFC-V) | ICODE-style vicinity labels and longer-range inventory contexts |
Regardless of type, a reader first discovers whether an NDEF mapping is present. On small labels this can mean reading a Capability Container or TLV-style metadata that declares NDEF memory size and access state. On file-oriented tags it can mean selecting and reading an NDEF file. That discovery step is what lets one phone handle a small NTAG poster sticker and a multi-kilobyte DESFire card with the same NDEF parsing logic.
Choosing a tag type is a memory, security, and reader-support decision. Choosing NDEF records is a behavior decision. Keep those decisions separate: a Type 2 NTAG label can be right for a public URL sticker, while a Type 4 DESFire tag can be right for a secured, file-structured credential.
Use the family names as deployment prompts, not as a simple ranking. Type 1 and Type 2 labels fit small public records such as one-time provisioning hints, read-only business-card data, URL redirects, and Bluetooth or Wi-Fi handover references when the payload is short and the lifecycle is controlled. Type 3/FeliCa belongs in a reader-support review for Japanese and wider Asian transit, e-money, membership, and ID workflows. Type 4 is the family to evaluate when a ticket, credential, or access workflow needs ISO 7816-style files, access conditions, or secured applet behavior. Type 5 maps to ISO 15693/NFC-V vicinity behavior, so library labels, product packaging, and healthcare or medication labels need placement and reader evidence before the longer coupling distance is trusted.
15.7 Quick Check: Tag Type Fit
15.8 NDEF Message Structure
NDEF turns tag bytes into records that many NFC devices can parse. It does not make the payload trustworthy by itself.
15.9 NDEF Record Planning
A tag that seems to open a URL, join Wi-Fi, or show text when you tap it is usually storing data as NDEF (NFC Data Exchange Format), the common format NFC readers understand. An NDEF message is a list of NDEF records, and each record is a typed container with a type, optional ID, and payload.
The record type is what lets a reader choose an action. A URI record says “this is a link”; a Text record says “this is text”; a MIME or External record says “this is app-specific structured data.” The tag is not running the workflow. It is presenting structured input that the phone and application decide how to handle.
For a maintenance label, a safe NDEF plan might use one URI record and one Text record. The URI record points to a controlled route such as https://ops.example.invalid/asset/PUMP-014. The Text record stores a short printed fallback such as PUMP-014, so support can compare the phone result with the visible label. The tag still does not authorize work; it only selects the asset and gives the application structured input to validate.
The release decision starts with capacity and lifecycle. If the selected Type 2 sticker has about 144 user bytes, a compact URI record plus a short fallback text record can fit comfortably. If the team later adds a JSON blob, long instructions, a signature, or multilingual fallback text, the payload can outgrow the tag even though the workflow idea is unchanged.
15.10 Record Patterns
Choose the simplest record pattern that carries the workflow safely.
15.11 Type Name Format and Byte Budget
Each NDEF record header carries a 3-bit TNF (Type Name Format) value that tells the parser how to interpret the type field.
| TNF | Meaning | Example |
|---|---|---|
| Well-Known Type | NFC Forum record type definition | U for URI, T for Text, Sp for Smart Poster |
| MIME media type | Internet media type | text/vcard, application/json |
| Absolute URI | Full URI used as the record type | https://example.invalid/schema |
| External Type | Vendor-namespaced type | android.com:pkg or a domain-owned app type |
Header flags frame the message: MB and ME mark message begin and message end, SR marks a short record with a payload under 256 bytes, and IL signals an ID field is present. A well-formed URI record can be compact because common prefixes such as https://www. can be represented with a prefix code instead of repeated text.
Do the byte budget before writing. In a short URI record, the record overhead includes a header byte, type-length byte, payload-length byte, the one-byte type field U, and the URI payload. A short Text record is similar: it has a header byte, type length, payload length, the one-byte type field T, a status byte, language code, and text. The message may also sit inside an NDEF TLV container with its own type, length, and terminator bytes on Type 2 style tags.
For the maintenance label, the URI tail after an abbreviated https:// prefix is roughly ops.example.invalid/asset/PUMP-014, and the fallback text is only PUMP-014. That plan leaves room for normal NDEF overhead on a small public tag. A plan that adds ?user=..., a long free-text location, or a serialized access policy should be rejected or moved to the backend.
15.12 Capacity, Write State, and Locking
Capacity and write state are release criteria, not cleanup details.
15.13 Validation and Security Boundary
Public NDEF is useful because it is easy to read. That also means it should not carry authority.
The same layering explains the security boundary. Type 2 and Type 5 labels are often excellent public pointers, but ordinary readable NDEF does not hide secrets from a phone. Type 4 tags can support file access conditions and larger payloads, but an NDEF file is still only one part of a credential system.
If a copied NDEF message can trigger the final action, the tag has been given too much authority. If it only opens a validated asset lookup that still checks user, device, state, and audit policy, the tag remains a replaceable pointer. When a maintenance label must prove authenticity, the NDEF record can carry a signed pointer or short token while the application verifies signature, freshness, asset state, and user policy outside the tag.
15.14 Write and Release Loop
A release loop prevents a tag from being treated as done just because a writer app returned success.
15.15 Common Review Findings
15.16 Check Your Understanding
15.16.1 Quick Check: Releasing an NDEF Tag
15.17 Matching Quiz: NDEF Review Artifacts
15.18 Ordering Quiz: Safe NDEF Tag Release
15.19 Summary
- NFC tag review starts with family, NDEF support, usable capacity, write state, physical fit, and release evidence.
- NDEF messages are structured as records with header flags, type information, optional IDs, and payloads that applications must validate.
- URI, Text, MIME, External, and composite records are useful when each record has a clear workflow role.
- Ordinary NDEF should carry context and routing data, not credentials, private data, unlock commands, long-lived secrets, or policy decisions.
- A tag is not ready for release until it has been written from the approved plan, read back, decoded, validated, field-tested, and tied to fallback and retest evidence.
15.20 Key Takeaway
NFC tag and NDEF choices should be based on memory, write protection, lifecycle, reader compatibility, and the action the encoded data should trigger.