27 NFC Tags and NDEF Format
Sammy the Sensor held up a tiny sticker: “This NFC tag can store a website address! But how does the phone know what is on it?” Max the Microcontroller explained, “NFC uses a language called NDEF – think of it as a universal template. No matter what phone you have, it can read the message because everyone follows the same rules. It is like writing a letter with a standard format: address first, then the message.” Bella the Battery added, “Tags come in different sizes. A Type 2 tag is like a small sticky note – great for a URL. A Type 4 tag is like an index card – big enough for encrypted payment information.” Lila the LED noted, “And here is a clever trick: instead of writing out ‘https://www.’ every time, the tag uses a single code byte to mean the same thing. That saves 12 bytes, which is a lot when your tag only holds 48!”
27.2 Learning Objectives
By the end of this chapter, you will be able to:
- Differentiate NFC Tag Types: Compare Type 1-5 tag specifications and justify the appropriate type for a given IoT application
- Construct NDEF Messages: Assemble valid NFC Data Exchange Format messages with correct TLV containers and record headers
- Design NDEF Records: Structure URI, text, Smart Poster, and MIME type records with proper prefix compression
- Evaluate Tag Selection Trade-offs: Assess tag memory, security, cost, and durability constraints to recommend optimal tags for deployment scenarios
- Calculate Transfer Times: Derive data transfer durations at 106, 212, and 424 Kbps NFC data rates including protocol overhead
27.3 Prerequisites
Before diving into this chapter, you should be familiar with:
- NFC Introduction and Operating Modes: Understanding NFC fundamentals, three operating modes, and relationship to RFID
- Networking Basics: Data encoding and protocol concepts
- RFID Fundamentals: Tag types and memory structures
This Series:
- NFC Introduction and Operating Modes - NFC fundamentals
- NFC Tags and NDEF Format - This chapter
- NFC Programming and Applications - Hands-on tag programming
- NFC Implementation and Best Practices - IoT integration and Python examples
Related Content:
- RFID Tag Types - Parent technology tag types
- Data Encoding - Data structure concepts
- Protocol Design - Protocol fundamentals
Learning:
- Quizzes Hub - Test your NDEF knowledge
- Tool Discovery Hub - Interactive NDEF builders
Think of NFC tags like different sizes of sticky notes:
- Type 1-2 tags are like small sticky notes (48-144 bytes) - perfect for a website URL or short message
- Type 4 tags are like index cards (4-32 KB) - can hold more complex data like encrypted payment information
- Type 5 tags are specialized for IoT sensors - like industrial labels with extra range
The NDEF format is like using a standard template for your sticky note so anyone can read it, whether they have an iPhone or Android phone. Without NDEF, it would be like writing in a language only your phone understands!
27.4 NFC Tag Types
NFC tag memory efficiency: NTAG213 has 180 bytes total, but only 144 bytes are user-accessible. The rest is reserved: UID (7 bytes), lock bits (3 bytes), capability container (4 bytes), and OTP/config pages. Worked example: To store a vCard with name (20 bytes), phone (15 bytes), email (30 bytes), and NDEF overhead (25 bytes), total = \(20 + 15 + 30 + 25 = 90 \text{ bytes}\). This fits in NTAG213 (144 bytes) with 54 bytes spare. But adding a 200-byte thumbnail image would require \(90 + 200 = 290 \text{ bytes}\) — exceeding NTAG213 capacity, necessitating NTAG215 (504 bytes). Tag cost scales with memory: NTAG213 = $0.25, NTAG215 = $0.40, NTAG216 = $0.50.
NFC tags come in different types with varying memory and capabilities:
| Type | Memory | Speed | Rewritable | Use Case | Example |
|---|---|---|---|---|---|
| Type 1 | 96 bytes - 2 KB | 106 Kbps | Yes | Simple marketing | Topaz |
| Type 2 | 48 bytes - 2 KB | 106 Kbps | Yes | Smart posters | MIFARE Ultralight |
| Type 3 | Variable | 212 Kbps | Yes/No | Transit, eSIM | Sony FeliCa |
| Type 4 | 4 KB - 32 KB | 424 Kbps | Yes | High-security | MIFARE DESFire |
| Type 5 | 256 bytes - 8 KB | 106 Kbps | Yes | IoT sensors | ISO 15693 |
For simple tasks (URL, text): Type 2 (cheap, ~$0.20) For payments, access: Type 4 (secure, encrypted) For IoT sensors: Type 5 (longer range within NFC spec) For read-only: Lock Type 2 after writing
27.5 NDEF (NFC Data Exchange Format)
NDEF is the standard data format for NFC, ensuring interoperability between devices.
27.5.1 NDEF Message Structure
27.5.2 Common NDEF Record Types
URI Record (open URL):
Type: U (URI)
Payload: https://example.com/product/123Text Record:
Type: T (Text)
Payload: "Tap to connect to Wi-Fi"Smart Poster:
Wi-Fi Configuration (Android):
Type: application/vnd.wfa.wsc
Payload: [Wi-Fi credentials encrypted]27.6 Worked Example: Selecting NFC Tags for a Museum Interactive Guide
Scenario: A natural history museum with 300 exhibits across 8 galleries wants to replace printed information cards with NFC-enabled interactive guides. Visitors tap their smartphones against NFC tags mounted on exhibit stands to receive multimedia content (audio narration, 3D models, and multilingual text). The museum has 450,000 visitors per year.
Step 1 – Define tag requirements:
| Requirement | Value | Rationale |
|---|---|---|
| Content per tag | URL to cloud-hosted exhibit page (60-80 bytes) | Multimedia content too large for tag memory – use URL redirect |
| Durability | 5+ year lifespan, 500,000+ taps | Heavy visitor traffic; replacing tags is labor-intensive |
| Environment | Indoor, 18-24C, no moisture exposure | Museum climate-controlled |
| Security | Tamper detection desirable | Prevent visitors from reprogramming tags with malicious URLs |
| Budget per tag | Under $2 (installed) | 300 tags, total budget $600 for tags |
| iPhone compatibility | Required | ~55% of museum visitors use iPhone |
Step 2 – Evaluate tag types:
| Tag Type | Memory | Speed | iPhone Support | Rewrite Protection | Price | Verdict |
|---|---|---|---|---|---|---|
| Type 1 (Topaz) | 96-2,048 bytes | 106 kbps | No (pre-iPhone 7) | Basic lock bit | $0.20 | Eliminated – too slow, limited phone support |
| Type 2 (NTAG213) | 144 bytes | 106 kbps | Yes (iPhone 7+) | One-time lock | $0.25 | Strong candidate – sufficient memory for URL, good price |
| Type 2 (NTAG215) | 504 bytes | 106 kbps | Yes (iPhone 7+) | One-time lock | $0.40 | Over-provisioned for URL, costs more |
| Type 4 (DESFire EV2) | 2-8 KB | 424 kbps | Yes | AES-128 authentication | $1.80 | Overkill for URL, but excellent security |
| NTAG424 DNA | 256 bytes | 106 kbps | Yes | AES-128 + URL authentication | $0.90 | Best balance: URL auth prevents tampering |
Step 3 – Decision and justification:
Selected: NTAG213 for standard exhibits, NTAG424 DNA for high-value or interactive exhibits.
- NTAG213 (240 of 300 exhibits): A URL like
https://museum.org/e/42fits in 45 bytes. The tag’s one-time lock permanently prevents reprogramming. At $0.25/tag, the 240-tag budget is just $60. - NTAG424 DNA (60 premium exhibits): For exhibits with augmented reality features or paid audio guides, the NTAG424’s SUN (Secure Unique NFC) authentication generates a one-time cryptographic signature appended to the URL. The museum’s server verifies this signature, preventing URL cloning or replay attacks. At $0.90/tag, the 60-tag budget is $54.
Total tag cost: $114 for 300 exhibits (well under $600 budget).
Step 4 – NDEF record design:
Each tag contains a single NDEF URI record:
- Standard exhibit:
Urecord withhttps://museum.org/e/42(22 bytes) - Premium exhibit (NTAG424):
Urecord withhttps://museum.org/e/42?sig=ABC123&ctr=7wheresigis a rotating AES-CMAC signature andctris a monotonic counter (prevents replay)
Why URL redirect instead of storing content on the tag? A 144-byte NTAG213 cannot hold a multilingual description, audio file references, and 3D model links. By storing a short URL, the museum can update exhibit content (add new languages, fix errors, change audio) without physically touching any tag. The cloud page detects the visitor’s phone language and serves appropriate content automatically.
Common Pitfalls
An NDEF message with incorrect TLV (Type-Length-Value) structure or mismatched length fields will be rejected by readers or parsed incorrectly. Fix: use a validated NDEF library (e.g., ndeflib) to construct messages rather than writing raw bytes manually.
NDEF-compatible tags require a terminator TLV (0xFE) after the last NDEF message TLV. Missing it causes some readers to fail to recognise the message. Fix: always include the 0xFE terminator byte after the last NDEF TLV when writing to tag memory.
Not all NFC tags store data in NDEF format. MIFARE Classic and some proprietary tags use non-NDEF memory layouts. Fix: verify NDEF compatibility in the tag’s datasheet before expecting standard NDEF libraries to read or write the tag correctly.
27.7 Summary
This chapter explored NFC tag types (Type 1-5) with their memory capacities, speeds, and use cases. Type 2 tags are ideal for simple smart posters, while Type 4 tags provide high security for payments. NDEF (NFC Data Exchange Format) ensures cross-platform interoperability by providing a standardized way to structure URLs, text, Smart Posters, and MIME records on NFC tags.
Understanding tag selection and NDEF structure enables you to design NFC solutions that work seamlessly across all NFC-capable devices, from iPhones to Android phones to embedded IoT readers.
27.11 What’s Next
Now that you understand NFC tag types and NDEF format, continue with these related chapters:
| Next Chapter | Focus Area |
|---|---|
| NFC Programming and Tag Writing | Hands-on NDEF record creation and tag read/write code |
| NFC Security and Best Practices | Tag cloning prevention, NTAG424 SUN authentication |
| NFC Real-World Applications | Deployment case studies in transit, retail, and healthcare |
| NFC Communication Fundamentals | Deeper dive into ISO 14443 modulation and anti-collision |
| RFID Fundamentals and Standards | Parent technology: frequency bands, tag types, ISO standards |