886  NFC Tags and NDEF Format

886.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Understand NFC Tag Types: Compare Type 1-5 tags and choose appropriate types for different applications
  • Master NDEF Format: Create and parse NFC Data Exchange Format messages
  • Design NDEF Records: Structure URI, text, Smart Poster, and MIME type records
  • Optimize Tag Selection: Select tag memory and capabilities based on use case requirements
  • Calculate Transfer Times: Estimate data transfer times at different NFC data rates

886.2 Prerequisites

Before diving into this chapter, you should be familiar with:

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!


886.3 NFC Tag Types

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
TipChoosing NFC Tag Type

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

886.4 NDEF (NFC Data Exchange Format)

NDEF is the standard data format for NFC, ensuring interoperability between devices.

886.4.1 NDEF Message Structure

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'background': '#ffffff', 'mainBkg': '#2C3E50', 'secondBkg': '#16A085', 'tertiaryBkg': '#E67E22'}}}%%
flowchart TD
    MSG[NDEF Message] --> REC1[Record 1<br/>Header + Payload]
    MSG --> REC2[Record 2<br/>Header + Payload]
    MSG --> REC3[Record 3<br/>Header + Payload]

    REC1 --> H1[Header<br/>TNF, Type, ID, Flags]
    REC1 --> P1[Payload<br/>URL: https://example.com]

    REC2 --> H2[Header<br/>TNF, Type, ID, Flags]
    REC2 --> P2[Payload<br/>Text: Hello NFC]

    style MSG fill:#2C3E50,stroke:#16A085,color:#fff
    style REC1 fill:#16A085,stroke:#2C3E50,color:#fff
    style REC2 fill:#16A085,stroke:#2C3E50,color:#fff
    style REC3 fill:#7F8C8D,stroke:#333,color:#fff

Figure 886.1: NDEF message structure with multiple records containing headers and payloads

886.4.2 Common NDEF Record Types

URI Record (open URL):

Type: U (URI)
Payload: https://example.com/product/123

Text Record:

Type: T (Text)
Payload: "Tap to connect to Wi-Fi"

Smart Poster:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'background': '#ffffff', 'mainBkg': '#2C3E50', 'secondBkg': '#16A085', 'tertiaryBkg': '#E67E22'}}}%%
flowchart LR
    SP[Smart Poster<br/>NDEF Message]

    SP --> URL[URL Record<br/>https://movie.com/trailer]
    SP --> TEXT[Text Record<br/>Coming Soon: Movie Title]
    SP --> MIME[MIME Record<br/>image/png poster]

    style SP fill:#2C3E50,stroke:#16A085,color:#fff
    style URL fill:#16A085,stroke:#2C3E50,color:#fff
    style TEXT fill:#16A085,stroke:#2C3E50,color:#fff
    style MIME fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 886.2: Smart poster NDEF message combining URL, text, and image records

Wi-Fi Configuration (Android):

Type: application/vnd.wfa.wsc
Payload: [Wi-Fi credentials encrypted]

Question: NFC operates at 13.56 MHz with data rates up to 424 Kbps. How long does it take to transfer a typical 4 KB NDEF message at maximum speed?

💡 Explanation: Let’s calculate the theoretical and practical transfer times:

Theoretical calculation: - Data size: 4 KB = 4,096 bytes = 32,768 bits - Data rate: 424 Kbps = 424,000 bits/second - Transfer time: 32,768 bits ÷ 424,000 bps = 0.0773 seconds = 77.3 ms

Practical overhead: Real-world transfer includes: - Anti-collision protocol: 10-20 ms (if multiple tags present) - Tag activation: 5-10 ms - Command/response overhead: Protocol wrapping adds 10-20% - Error checking: CRC calculation and validation

Actual transfer time: 100-150 ms for 4 KB

Data rate modes:

Mode Data Rate 4 KB Transfer
106 Kbps Slowest (NFC-A) 308 ms
212 Kbps Medium (NFC-F) 154 ms
424 Kbps Fast (NFC-F) 77 ms
848 Kbps Maximum (rarely used) 39 ms

Why not always use 848 Kbps? - Requires better RF conditions - Higher power consumption - Less compatible (not all devices support it) - 424 Kbps is practical maximum for most applications

Real-world transfer examples:

Mobile payment: - Data size: ~500 bytes (payment token) - Transfer time: ~10-20 ms - User perceives: Instant (< 100 ms threshold)

Business card transfer: - Data size: 1 KB (vCard with photo) - Transfer time: ~40-60 ms - User experience: Seamless

App deep link: - Data size: 200 bytes (URL) - Transfer time: ~5-10 ms - Launches app in < 500 ms total

Photo transfer (NOT recommended for NFC): - Data size: 500 KB (compressed JPEG) - Transfer time at 424 Kbps: 9.4 seconds - Use Bluetooth instead! (1-2 Mbps = 0.5 seconds)

Best practices: - NFC: Small data (< 8 KB) - URLs, tokens, handshakes - NFC + Bluetooth: Use NFC to pair, Bluetooth for bulk transfer - NFC + Wi-Fi Direct: NFC handshake, Wi-Fi for large files

The “touch-and-go” UX requires transfers complete in < 300 ms, limiting practical payloads to ~8 KB!

Question: Which NFC operating mode allows two smartphones to exchange data without either acting as a tag?

💡 Explanation: NFC has three distinct operating modes, each serving different use cases:

1. Peer-to-Peer (P2P) Mode:

How it works: - Both devices are active (generate RF field) - Uses LLCP (Logical Link Control Protocol) - Symmetric communication (neither is “master”) - Alternating field generation (taking turns)

Applications: - File transfer: Android Beam (deprecated), photos, contacts - Bluetooth pairing: Quick handshake to exchange BT MAC addresses - Wi-Fi credentials: Share network password between phones - Gaming: Multiplayer setup, character exchange

Example flow:

Phone A                    Phone B
   |                          |
   |-- Generate RF field ---->|
   |<-- Data response --------|
   |                          |
   |<-- Generate RF field ----|
   |-- Data response -------->|

2. Read/Write Mode:

How it works: - Active reader (smartphone) generates field - Passive tag powered by reader’s field - Asymmetric: Reader initiates, tag responds

Applications: - Smart posters: Read URL/info from NFC tag - Product authentication: Verify genuine products - Asset tracking: Read/write inventory data - Smart home control: Tap tag to trigger automation

3. Card Emulation (CE) Mode:

How it works: - Device emulates contactless smart card - External reader (POS terminal) generates field - Device acts as passive tag

Applications: - Mobile payments: Apple Pay, Google Pay - Transit: Digital transit cards - Access control: Building entry badges - Loyalty cards: Digital reward cards

Why other options are wrong:

B (Card Emulation with both devices): - Card Emulation requires ONE reader and ONE card - Both can’t emulate cards simultaneously - Would be like two credit cards trying to pay each other!

C (Read/Write bidirectional): - Read/Write is inherently asymmetric - Reader is always active, tag is always passive - Tag can respond but cannot initiate

D (Active mode): - “Active mode” describes the RF field generation - BOTH P2P devices can be active, but this describes HOW, not WHAT mode - Needs LLCP protocol layer to implement P2P functionality

Real-world P2P example:

Android Beam (legacy, but illustrates P2P): 1. User taps two NFC phones back-to-back 2. P2P mode activates 3. LLCP establishes connection 4. NDEF message exchanged (URL, contact, etc.) 5. For large files, hands off to Bluetooth 6. User separates phones

Modern P2P alternatives: - Apple AirDrop: Wi-Fi Direct + Bluetooth - Nearby Share (Google): BLE + Wi-Fi Direct - Quick Share (Samsung): Similar approach

P2P mode is primarily used for pairing handshakes, not bulk transfer, in modern implementations!

Question: What is NDEF (NFC Data Exchange Format), and why is it important for NFC interoperability?

💡 Explanation: NDEF (NFC Data Exchange Format) is the universal language that enables NFC interoperability across all devices and platforms:

What is NDEF?

A standardized data format defined by the NFC Forum that specifies how to: - Structure data on NFC tags - Encode different data types (URLs, text, contacts, etc.) - Represent multiple records in a single message - Ensure cross-platform compatibility

Without NDEF: - Apple might encode URLs one way, Android another - NFC tag written on iPhone unreadable on Android - Each manufacturer invents proprietary formats - Chaos and incompatibility

With NDEF: - Tag written on ANY device readable on ALL NFC devices - Guaranteed interoperability - Predictable behavior across platforms

NDEF Structure:

  • NDEF Message
    • Contains one or more NDEF Records
  • Each NDEF Record includes:
    • A Header (flags, type length, payload length)
    • A Type (URI, Text, Smart Poster, MIME, etc.)
    • An optional ID
    • A Payload (the actual data)

NDEF Record Types (RTD):

Well-Known Types: 1. URI (Universal Resource Identifier) - Most common: https://example.com - Tel: tel:+1-555-1234 - SMS: sms:+1-555-1234 - Example: \x03example.com (0x03 = https://)

  1. Text
    • Multilingual support with language codes
    • UTF-8 encoding
    • Example: “en” + “Hello World”
  2. Smart Poster
    • Combines URI + Title + Action + Icon
    • Rich interactive experience
    • Example: Product page with name and image
  3. MIME Types
    • vCard: Contact information
    • text/x-vCard: Business cards
    • application/json: Structured data

Real-world NDEF example:

Business card NFC tag (NTAG215, 504 bytes):

NDEF Message (180 bytes total):

Record 1: Text (Name)
  - Header: MB=1, ME=0, SR=1, TNF=0x01
  - Type: T (Text)
  - Payload: "en" + "John Smith"

Record 2: URI (LinkedIn)
  - Header: MB=0, ME=0, SR=1, TNF=0x01
  - Type: U (URI)
  - Payload: 0x03 + "linkedin.com/in/johnsmith"

Record 3: MIME (vCard)
  - Header: MB=0, ME=1, SR=0, TNF=0x02
  - Type: text/x-vCard
  - Payload: BEGIN:VCARD
            VERSION:3.0
            N:Smith;John
            TEL:+1-555-1234
            EMAIL:john@example.com
            END:VCARD

Cross-platform behavior:

When iPhone taps this tag: - Reads NDEF records - Recognizes vCard MIME type - Offers to add contact to Contacts app - Detects LinkedIn URL, offers to open

When Android taps same tag: - Reads identical NDEF records - Recognizes vCard MIME type - Offers to add contact to Contacts app - Detects LinkedIn URL, opens in browser/app

NDEF advantages:

For developers: - Write once, run anywhere - Standard libraries available (Android, iOS, embedded) - No platform-specific code needed

For users: - Consistent experience across devices - Tags work everywhere - Future-proof (new devices support old tags)

For IoT deployments: - 1 million tags work with iPhone AND Android - No need to print separate versions - Reduces maintenance and support

NDEF Limitations:

Size constraints: - NTAG213: 144 bytes - NTAG215: 504 bytes - NTAG216: 888 bytes - Must fit data in limited space

No built-in encryption: - NDEF is plaintext format - Encryption must be added at application layer - NTAG424 adds built-in AES encryption

Static content: - Basic NDEF is static (doesn’t change) - For dynamic content, use URL that returns different data

Why other options are wrong:

A (Encryption protocol): - NDEF is a DATA FORMAT, not encryption - Security is separate (though NTAG424 adds it)

C (Hardware specification): - NDEF is pure software/data specification - Antenna design is separate (ISO 14443)

D (Frequency modulation): - Modulation is defined by ISO 14443 - NDEF is the data payload format

NDEF is the “HTTP of NFC” - a universal format that makes everything work together!

886.5 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.

886.6 What’s Next

Now that you understand NFC tag types and NDEF format, the next chapter provides hands-on programming examples for reading and writing NFC tags, along with real-world application scenarios.

Continue to: NFC Programming and Applications