NFC NDEF Format Explained

NDEF message and record structure — the on-tag data model

Tap a phone against a sticker and a web page opens — no app, no pairing, nothing to install. To everyone watching, that is a small piece of magic; to the person who encoded the sticker, it is a strict little data structure that will quietly refuse to work if a single byte sits in the wrong place. A botched encoding rarely fails politely in the lab — it tends to fail in the field, across a production run that has already shipped. Almost everything below is about respecting rules that turn out to be far less forgiving than they look. NDEF is a binary data format defined by the NFC Forum that specifies how information is structured on an NFC tag so that any compliant reader (including every modern smartphone) can interpret it consistently. Understanding the message-and-record hierarchy and the header byte layout is the foundation for planning memory use, debugging encoding errors and designing consumer-facing NFC programmes.

• One message per tag, multiple records per message. Each NFC tag stores exactly one NDEF message. The message is a container that holds one or more NDEF records arranged in sequence. A Smart Poster use case may store a URI record plus a Text record plus an action record in the same message; a simple URL tag stores just one URI record.
• NDEF record header byte. Every record begins with a header byte encoding five flag bits (MB message begin, ME message end, CF chunk flag, SR short record, IL ID-length present) and a three-bit TNF (Type Name Format) value. The MB and ME flags mark the first and last records in the message, letting the parser discover message boundaries.
• TNF (Type Name Format) values — 0x00 Empty, 0x01 NFC Forum well-known type, 0x02 MIME media type (RFC 2046), 0x03 Absolute URI (RFC 3986), 0x04 NFC Forum external type, 0x05 Unknown, 0x06 Unchanged (chunk continuation). The TNF value tells the parser how to interpret the Type field that follows.
• Type, ID and Payload fields. After the header byte and length fields comes the Type field (e.g., 'U' for URI well-known, 'T' for Text), optional ID field (used when multiple records in the same message need to be distinguished by application ID), and the Payload field carrying the actual record content. Length fields preceding each variable-length section let the parser safely skip unknown record types.
• Short record optimization: the SR (Short Record) flag indicates payload length fits in a single byte (up to 255 bytes), allowing the length field to be 1 byte instead of 4. This saves 3 bytes per record and is the default for most consumer-facing NDEF content, which rarely exceeds 255 bytes.
• NDEF on tag memory. On NFC Forum Type 2 tags (NTAG 213/215/216, most common), the NDEF message is stored beginning at a fixed memory offset (page 4 in the user area), preceded by a TLV (Type-Length-Value) wrapper that identifies the NDEF region. The tag may also hold terminator TLVs, lock bytes and configuration pages outside the NDEF region.
• Worked binary example: a minimal URL NDEF for 'https://example.com' encodes as: TLV 0x03 0x10 (NDEF TLV type, length 16 bytes) | header 0xD1 (MB=1, ME=1, SR=1, TNF=0x01) | TYPE_LEN 0x01 | PAYLOAD_LEN 0x0C | TYPE 'U' (0x55) | PAYLOAD 0x04 'example.com' (URI prefix 0x04 = 'https://') | terminator 0xFE. Total 20 bytes on-tag including the TLV wrapper. This is the byte-accurate pattern every NDEF parser on iPhone and Android expects at page 4.
• Chunked records and the CF flag. Records whose payload exceeds the tag's transmission frame (rare on Type 2 tags; common on Type 4 large NDEF files) can be chunked by setting CF (Chunk Flag) on all but the last chunk. Chunked records share a single TNF/TYPE header and concatenate payload fragments. Consumer-facing tags almost never use chunking because the total NDEF message fits in a single record; Type 4 tags (DESFire, NTAG 424 DNA) may emit chunked ReadBinary responses, which the reader middleware reassembles transparently.

NDEF record types — URI, Text, Smart Poster, vCard, Wi-Fi, Bluetooth and application-launch

The NFC Forum defines a standard vocabulary of well-known record types that every compliant reader interprets consistently. This section covers the most common record types encountered in consumer-facing NFC programmes, the memory footprint of each, and the smartphone-side behaviour when a user taps the tag.

• URI record (TNF 0x01, Type 'U'). The most common NDEF record type in production NFC programmes. Stores a URL that the smartphone opens automatically on tap. The payload begins with a 1-byte URI prefix code followed by the remainder of the URL. Prefix codes replace common prefixes like `http://www.` (0x01), `https://www.` (0x02), `https://` (0x04), `tel:` (0x05), `mailto:` (0x06), saving 7-12 bytes versus storing the full string.
• Text record (TNF 0x01, Type 'T'). Stores plain text in UTF-8 or UTF-16 encoding with an IANA language code. Used for simple labels, display strings and announcements that a reading app can render as-is. Text records are rarely the primary payload for consumer URL tags (where URI records are used) but are common in Smart Poster records as a descriptive title.
• Smart Poster record (TNF 0x01, Type 'Sp'). A composite record carrying a URI, one or more Text records (as titles in different languages), an optional icon and an action indicator. The Smart Poster record type dates from early NFC marketing campaigns and is less used today because a simple URI record achieves the same result on both iOS and Android without the extra bytes.
• vCard record (TNF 0x02, Type 'text/vcard'). An NDEF record carrying a MIME-typed vCard 3.0 or 4.0 payload with name, phone, email, company and address fields. On tap, iPhone offers to save the contact to Contacts.app; Android offers to save to the contact store. Memory usage is typically 100-300 bytes depending on the number of vCard fields and whether a photo is included.
• Wi-Fi Alliance Wireless Configuration record. A Wi-Fi-Alliance-specified record carrying a Wi-Fi Configuration Token (or Wi-Fi Password Token) with SSID, authentication type, encryption key and passphrase, encoded in the WSC TLV format (16-bit Type, 16-bit Length, Value). The MIME type is `application/vnd.wfa.wsc` per Wi-Fi Alliance Wi-Fi Simple Configuration. On tap, Android prompts to join the Wi-Fi network; iPhone support has been inconsistent historically (iOS 11+ added partial support via Core NFC). Common in hotel check-in, restaurant guest Wi-Fi and conference venue tags.
• Bluetooth handover record (TNF 0x02, Type `application/vnd.bluetooth.ep.oob`). Carries a Bluetooth device address and class of device for automatic pairing on tap. Widely used in pair-on-tap speakers, headphones and IoT devices. Handover to Bluetooth is a standardized NFC Forum flow; the NFC tap triggers the pairing, and subsequent communication runs over Bluetooth.
• Application launch record (Android AAR). An Android-specific NDEF external-type record (`android.com:pkg`) carrying a package name. On tap, Android launches the specified app (or redirects to the Play Store if the app is not installed). iOS uses a different mechanism (Universal Links in the URI payload) to achieve app-launch behaviour; cross-platform NFC programmes typically use a URI record that resolves to a Universal Link which in turn routes users to the iOS or Android app.

Memory planning — fitting your NDEF content into NTAG 213, 215, 216 and 424 DNA

Memory planning is the single most common implementation challenge in production NFC programmes. Consumer URLs can exceed the 144-byte budget of NTAG 213 if tracking parameters or campaign IDs are included; vCards with embedded photos rarely fit on NTAG 213 or even 215. This section provides concrete memory budgets and planning heuristics to avoid encoding failures at production time.

• NTAG 213 (144 bytes usable NDEF memory). The workhorse of high-volume consumer NFC. Sufficient for URLs up to ~130 characters (with prefix compression), basic plain-text vCards without photos, simple Wi-Fi credentials for short SSID / passphrase combinations. NTAG 213 is the cost-optimal choice for URL-based marketing, loyalty tags and digital business cards with minimal contact fields.
• NTAG 215 (504 bytes usable NDEF memory). Mid-tier capacity that accommodates longer URLs (up to ~490 characters), vCards with multiple phone numbers, emails and addresses, multi-record messages (URI + Text + vCard), and Wi-Fi configurations with long passphrases. Popular for premium digital business cards, luxury brand authentication pre-2020, and consumer product NFC where the payload exceeds NTAG 213's budget.
• NTAG 216 (888 bytes usable NDEF memory). The largest single-chip NFC Forum Type 2 option. Accommodates vCards with embedded photos (base64-encoded in the vCard), complex multi-record messages, embedded JSON data payloads for IoT use cases, or tag-level configuration data beyond the URL.
• NTAG 424 DNA (256-byte NDEF file inside 416 bytes total user memory; dynamic SUN mirroring). Premium authenticated-NFC chip with AES-128 Secure Dynamic Messaging (SDM, also marketed as 'SUN' Secure Unique NFC). The 416 bytes of memory are organized as an ISO/IEC 7816-4 file system: 32-byte capability container (CC), 256-byte NDEF file (E104) and a 128-byte protected data file. NDEF capacity is therefore 256 bytes — smaller than NTAG 216's 888-byte single-file user memory — but the SDM/SUN feature dynamically mirrors a cryptographic CMAC, the tag UID and a monotonic read counter into the URI record at read time, so the static-NDEF approach of pre-encoding a URL must be reconciled with the dynamic-mirror template syntax. Memory planning for NTAG 424 DNA focuses on URL template design (PICCData / Enc / CMAC mirror placeholders) plus the 128-byte protected data file budget, not raw NDEF byte budgeting.
• URL template design for tracking and personalization. Most production NFC programmes embed an identifier in the URL (e.g., `https://go.brand.com/?id=X` where X is unique per tag). The identifier length, base-URL length, and any additional query parameters (UTM campaign tags, locale preferences) must be summed against the tag's NDEF budget. Shorter branded domains and compact identifier encodings (Base62 rather than UUIDs) dramatically expand what fits on NTAG 213.
• Memory headroom and firmware overhead. The advertised 'usable NDEF memory' figures already account for NDEF TLV wrappers and headers. Additional overhead from multi-record messages (MB/ME flags and per-record headers) is typically 5-10 bytes per record beyond the first. Leave 5-10% memory headroom in your plan to accommodate future payload changes without re-sourcing to a larger chip.
• ASCII-mirror memory cost (NTAG 21x). If the URL template uses the NTAG 21x ASCII mirror feature to splice UID (14 chars) and/or NFC counter (6 chars) into the URL at read time, the placeholder 'X' characters in the encoded template consume memory just like literal characters. For a UID+counter mirror the template must reserve 20 bytes at the exact MIRROR_PAGE + MIRROR_BYTE offset; plan this before choosing NTAG 213 vs 215 because the mirror placeholders are permanently frozen once the template is encoded.

Encoding workflows — SDKs, bureau encoding and production-line pre-encoding

There are three dominant encoding workflows for getting NDEF content onto NFC tags: self-encoding with a consumer or professional SDK, bureau encoding by a service provider after tag sourcing, and production-line pre-encoding during tag manufacturing. This section describes the tradeoffs and when each workflow is appropriate, including Proud Tek's production-line pre-encoding service.

1. Step 1
   Consumer / small-batch self-encoding. A smartphone app (NFC Tools on iOS / Android, NXP TagWriter on Android, Flipper Zero or Proxmark on desktop) encodes tags one at a time. Suitable for prototyping, very small batches (under 100 tags), or in-field updates to a handful of tags. The workflow is: open the app, compose the NDEF message, tap the blank tag to encode. Throughput is limited to roughly 60-200 tags per hour depending on the app and device.
2. Step 2
   Professional SDK encoding: a desktop or server-side application using a USB / network reader (ACR122U, HID OMNIKEY, Identiv uTrust family) and an SDK (NFC Tools SDK, PC/SC APDUs, NXP TagXplorer, libnfc) encodes tags in batches. Throughput scales to 500-2000 tags per hour with batch feeding; unique per-tag content (URLs with embedded IDs, personalized vCards) is supported by generating each NDEF payload programmatically from a database.
3. Step 3
   Bureau encoding after tag sourcing. Some NFC programme operators source blank tags and ship them to an encoding bureau for third-party encoding before distribution. This introduces an extra logistics step and split ownership of encoding quality; it survives mainly in programmes where the tag supplier cannot or will not encode (historically common before pre-encoding became a routine service).
4. Step 4
   Production-line pre-encoding (Proud Tek). The encoding is integrated into the label-manufacturing line, so every tag leaves the factory pre-encoded, verified and optionally locked. Proud Tek's encoding line handles unique per-tag content (unique URL per tag, sequential or randomized IDs), common-content bulk encoding (same URL or vCard on every tag), multi-record NDEF messages, and NTAG 424 DNA URL-template + SUN configuration. Throughput reaches 10k-50k tags per day per line.
5. Step 5
   Encoding-verify QC: every tag on the Proud Tek line is read-verified after encoding: the encoded NDEF payload is read back and compared to the intended payload; mismatches are automatically rejected and replaced. The output QC report lists each tag's TID (unique hardware identifier), encoded NDEF content, and pass/fail status. This report is delivered as a CSV / JSON file alongside the physical tags.
6. Step 6
   Locking strategy: after encoding, tags can be locked using NTAG lock bytes (static lock, irreversible) or password protection (32-bit PWD with reversible unlock for authorized updates). Locking is essential for consumer-facing deployments to prevent malicious rewriting; Proud Tek applies locking per the customer specification during the same encoding pass.

iPhone vs Android behavior — what actually happens when a user taps

Despite NDEF being a cross-platform standard, real-world user experience differs subtly between iPhone and Android. Understanding these behavioral differences is essential for designing NFC programmes that work consistently across both ecosystems and avoid edge cases where a tag works on one platform but not the other.

• iPhone background tag reading (iOS 14+). iPhone XS and later running iOS 14 or newer automatically read NDEF tags in the background while the screen is unlocked, without requiring any app to be open. A URI record triggers Safari (or the user's default browser) to open the URL. Older iPhones (iPhone 7 through iPhone X with iOS 13) require launching Apple's built-in NFC Tag Reader in Control Center or an app calling Core NFC to read a tag.
• Android background tag reading. Android phones with NFC enabled read NDEF tags in the background whenever the screen is on and the phone is unlocked. The URI record routes to the default browser, the Play Store for apps with AAR records, or the relevant system app (Contacts for vCards, Settings for Wi-Fi). Background reading has been supported since Android 4.0 (2011), making Android the more permissive platform historically.
• Deep link versus URI routing. iPhone uses Universal Links (HTTPS URLs registered to an app) and App Clips to route NFC-triggered URLs into apps without manual routing on the part of the NFC programme. Android uses App Links (also HTTPS-based) plus legacy AAR records. Cross-platform programmes should prefer Universal Links / App Links over AAR, because AAR is Android-only and Universal Links work without any Android-specific record.
• Password-protected and authenticated tags. NTAG 213/215/216 password protection and NTAG 424 DNA AES-128 authentication require a custom app to exchange the authentication APDUs. The background NDEF reader on iPhone and Android does not perform authentication; it simply reads the open NDEF memory. For NTAG 424 DNA SUN-mirror URLs, the SUN value is automatically included in the mirrored URI record and is validated on the server-side without any phone-side authentication exchange.
• HCE (Host Card Emulation) versus tag reading. Both iOS and Android can emulate NFC tags (HCE mode) in addition to reading them. HCE lets a phone appear as an NDEF tag to an external reader, enabling dynamic NFC use cases (digital business cards that update via the app, loyalty programmes). HCE is outside the NDEF-on-tag scope but is worth mentioning because many 'NFC business card' programmes mix physical tag distribution with phone-based HCE for their users.
• Cross-platform testing: every NFC programme should test on at least iPhone XS, iPhone 14, Pixel 6 and Samsung Galaxy S22 (or equivalents) before mass deployment. Differences in NFC controller sensitivity, tap-zone size and default-browser behaviour can surface corner cases (tags read inconsistently on certain phones, URLs that open in a webview rather than the browser) that pilot testing catches before production rollout.

Locking, password protection and tamper-evidence strategies

Production NFC programmes need a strategy for preventing end-user modification of encoded tags. The options range from irreversible static locking through password protection to cryptographic authentication with NTAG 424 DNA. This section compares the options against common threat models and helps buyers choose the right protection level for their application.

• Static NDEF lock: NTAG 21x family supports irreversible locking of the NDEF memory region by setting lock bits after encoding. Once locked, the tag cannot be rewritten; any attempt to write returns an error. Suitable for static-URL consumer tags where the URL will never change. Throughput-efficient because locking is a one-shot operation during production encoding. Irreversible: a locked tag with a bad URL must be replaced.
• Password protection (NTAG 213/215/216). A 32-bit PWD is set at encoding time and can be reversibly set / cleared. Read access can optionally require PWD (for private tags); write access always requires PWD. Useful for consumer-facing tags that may need occasional reprogramming (campaign updates, promotional URL rotation) while blocking casual modification.
• AUTH0 and AUTHLIM settings. NTAG 21x tag configuration pages control how many pages are password-protected (AUTH0) and how many incorrect password attempts are allowed before the tag locks permanently (AUTHLIM). Production configurations typically set AUTHLIM = 7 to allow some operator retry while blocking brute-force attacks.
• NTAG 424 DNA SUN (Secure Unique NFC). The flagship anti-counterfeit protection. Each NDEF read includes a cryptographic Message Authentication Code (CMAC) and a monotonic read counter mirrored into the URL at read time. A backend server can verify the CMAC using the tag's AES-128 key and detect clones (which cannot produce valid CMACs) and replay attacks (stale counter values). SUN is the industry-standard choice for luxury-goods authentication, high-value consumer-goods validation, and brand-protected digital-twin NFC programmes.
• Originality signature: NTAG 213/215/216 and NTAG 424 DNA include a 32-byte ECDSA signature over the TID (Tag ID) signed by an NXP master key. A backend server that knows the NXP public key can verify that the tag is a genuine NXP chip. This protects against fake chips from unauthorized manufacturers but does not protect against chip-level cloning by anyone with access to the signature (NTAG 424 DNA SUN solves that problem with per-read cryptography).
• Tamper-evident form factor. Beyond cryptography, physical tamper-evidence (void-sticker substrates, frangible adhesives, sealed enclosures) detects attempts to remove and reattach a tag. Proud Tek offers void-label and frangible-face-stock options alongside standard NFC stickers; choose a physical tamper-evident construction if your threat model includes removing a genuine tag and reattaching it to a counterfeit product.

Common encoding pitfalls and field-debugging techniques

Encoding bugs have a cruel sense of timing: the tag that reads perfectly on the bench is the same one that does nothing on a customer's phone, a few weeks and one full production run later. Every NFC programme encounters the same handful of encoding bugs. Miscounted memory, wrong URI prefix byte, missing terminator TLV, locked CC with a broken URL. Knowing which symptom maps to which cause saves hours of back-and-forth with the encoding vendor and prevents rolling out tens of thousands of bricked tags. This section catalogues the pitfalls Proud Tek's encoding QC team sees most often and the debugging techniques that diagnose them in the field without a lab reader.

• Symptom: tag reads on Android but not iPhone. Almost always a missing or wrong URI prefix byte. iOS Core NFC is stricter than Android about well-formed RTD-URI records; a payload that starts with '0x00 https://example.com' (prefix code 0x00 = none, then literal 'https://') works on Android but fails iOS launch. Fix: use prefix 0x04 ('https://') followed by 'example.com'. Debug test: tap on iPhone with NFC Tools. If the app reads the URL but Safari does not auto-launch, prefix is the likely cause.
• Symptom: tag reads partial URL or garbage. Terminator TLV 0xFE is missing or the NDEF length byte is wrong. Parsers read the length prefix and assume everything within that many bytes is the record payload; if the length under-reports, the URL is truncated; if it over-reports, the parser reads past the record into lock bytes or uninitialised memory. Fix: verify TLV length equals actual NDEF message byte count, and confirm terminator 0xFE follows the message.
• Symptom: first tap shows URL, subsequent taps show nothing. Classic static-lock-with-wrong-AUTH0 pattern. The tag was locked while AUTH0 = 0x04, so every READ is now rejected because the reader did not authenticate. Or CFG1.ACCESS was set to protect reads. Fix at encoding time: set AUTH0 to a page above the NDEF content, or disable read-protection in CFG1. In the field: tag is unrecoverable unless you still have the PWD.
• Symptom: counter mirror works on day 1 but shows 0x000000 later — CFG1.ACCESS.NFC_CNT_EN was never set, so the counter doesn't increment. Or the mirror points to the wrong byte offset and the counter increments but isn't being spliced into the URL. Debug: dump pages 0-end with FAST_READ (0x3A 0x00 <end>) on a Proxmark3 or ACR1252U and confirm MIRROR_PAGE / MIRROR_BYTE align to the URL's placeholder position.
• Symptom: 5% of tags fail read-verify at encoding. Antenna-detune issue on the encoding line or ESD damage during reel handling. The ATQA response arrives but GET_VERSION times out. Fix: re-tune the encoding-antenna resonance with a vector network analyzer (target 13.56 MHz ± 200 kHz, Q 20-40) and confirm ESD wristband / ground-mat protocol on the line. Chronic 5%+ reject rates usually indicate a converter tuning problem, not a chip defect.
• Symptom: Android reads URL but the browser opens with a prompt 'Open in app?'. The URL is registered as an App Link for an app the user has not chosen as default. The system behaviour is correct NFC-wise; the user experience issue is in App Link configuration. Fix at the domain level (assetlinks.json on the target server) and in the target app's manifest, not in the NFC payload.
• Symptom: NFC Tools shows correct NDEF but browser opens a different URL. A URL-shortener chain or HSTS redirect is catching the original URL and rewriting it. Test with a direct URL (no shortener) to confirm the tag vs. the redirect path. For analytics-critical programmes, avoid double-redirects; host the landing page on the brand's own domain with minimal hops.
• Diagnostic reference readers: for field QC, the ACR1252U (USB, ~USD 35) with NFC Tools desktop, or an Android phone running NFC TagInfo by NXP, gives a byte-accurate dump of the entire memory. For deeper analysis (counter inspection, signature verification, failed-write troubleshooting) use a Proxmark3 RDV4 with the 'HF MFU' or 'HF SEARCH' commands. Keep at least one reference reader at every installation site for on-site triage.

Proud Tek production encoding workflow and buyer engagement

To translate the technical concepts above into an actual production programme, here is how Proud Tek engages with buyers from specification through bulk shipment. The workflow applies across NFC stickers, cards, wristbands, keychains and embedded-tag products.

1. Step 1
   Specification intake: buyers provide: chip selection (NTAG 213 for URL tags up to 130 chars, NTAG 215 for longer or multi-record, NTAG 216 for large payload, NTAG 424 DNA for authenticated), NDEF content template (URL pattern with variable ID placeholder, vCard schema, Wi-Fi config, custom payload), lock / password strategy, and form factor (sticker dimensions, card type, wristband material).
2. Step 2
   Sample pass: a 25-100 tag sample batch is produced and shipped within 5-7 business days with the full encoding applied. Buyers test the samples on target devices (iPhone, Android, vendor app) and confirm the end-to-end user experience before production commit. Sample QC reporting is included (same CSV format as production).
3. Step 3
   Unique-per-tag content generation. For programmes with unique identifiers per tag, buyers supply either a pre-generated list of IDs (CSV / JSON) or a generation specification (prefix + sequential range, random alphanumeric, specific character set). Proud Tek's encoding line reserves the ID range, applies it during encoding, and returns the ID-to-TID mapping in the QC report.
4. Step 4
   NTAG 424 DNA programming. For authenticated NFC programmes, Proud Tek configures the AES-128 keys (customer-supplied key or factory-generated with secure key export), sets the SUN message template, and configures the NDEF URL pattern with dynamic mirror placeholders. The per-tag AES key, AES-ID and file configuration are exported in the encrypted QC file for the buyer's backend authentication system.
5. Step 5
   Production lead time and throughput. Standard NDEF-encoded NFC orders ship in 2-4 weeks from PO for stock chip models; custom configurations (NTAG 424 DNA SUN, custom-shape printed stickers, embedded tags) run 4-8 weeks. Production throughput is 10k-50k tags per day per encoding line; very large programmes coordinate multi-line scheduling with 4-6 weeks of advance planning.
6. Step 6
   Integration handoff: the final shipment includes the physical tags, the QC CSV / JSON file (each tag's TID, encoded NDEF, encoded URL including any unique ID, lock / auth status), and for NTAG 424 DNA programmes the encrypted key-export file for the buyer's backend. Optional integration support includes sample backend validation code, iOS / Android app SDK integration guidance and analytics-pipeline connector documentation.

FAQ