# NFC NDEF Format Explained — Records and Encoding

URL: https://proudtek.com/guides/nfc-ndef-format-explained/
Source URL: https://proudtek.com/guides/nfc-ndef-format-explained/
Generated: 2026-03-16T01:42:30.697Z
Kind: article
Publisher: Proud Tek Co., Limited
Author: Nancy Wu (NFC Product Specialist)
Published: 2026-04-19
Last Modified: 2026-06-10T18:00:00Z
Reviewed By: Proud Tek Editorial Team
Last Reviewed: 2026-06-10T18:00:00Z
Credentials: ISO 9001:2015, ISO 14001:2015, RoHS Compliant, CE Marking, REACH Compliant
Image: https://proudtek.com/landing-images/ntag213-nfc-sticker.jpg
Image Alt: NFC NDEF data format diagram showing message records URI prefix compression and tag memory layout

## Description
A practical implementer's guide to the NFC Data Exchange Format (NDEF). The standard data structure NFC tags use to store URLs, vCards, Wi-Fi configs,...

## Summary
- A practical implementer's guide to the NFC Data Exchange Format (NDEF).

## Buyer Guidance
- Best for: NFC NDEF Format Explained — Records and Encoding supports RFID and NFC evaluation, comparison, and sourcing decisions.
- Compare first: Compare NFC NDEF Format Explained — Records and Encoding against reader compatibility, chip family, material, and deployment environment.
- What to confirm: Confirm target application, compatibility requirements, customization needs, quantity, and sample expectations before quoting NFC NDEF Format Explained — Records and Encoding.

## FAQ
- Q: Can Proud Tek pre-encode NDEF data on NFC tags during production?
  A: Yes. Every NFC product on our catalogue (NTAG 213/215/216 stickers, NTAG 424 DNA tags, NFC business cards, wristbands, keychains and embedded tags) can be pre-encoded on our production lines with your NDEF content. Common encoding patterns include: a unique URL per tag with a sequential or randomized ID; a common URL across the batch; vCard records with customer-supplied contact fields; Wi-Fi configuration records with SSID and passphrase; and multi-record messages combining URI + Text + application identifiers. Each tag is read-verified after encoding, optionally locked or password-protected per your specification, and shipped with a QC CSV listing TID, encoded NDEF content and verification status for each tag.
- Q: What is the maximum URL length that fits on NTAG 213 with NDEF encoding?
  A: NTAG 213 has 144 bytes of NDEF-usable memory after subtracting TLV wrappers and NDEF record headers. With URI prefix compression applied to the leading `https://www.` or `https://`, a typical URL of approximately 130 characters fits on NTAG 213. URLs longer than that require NTAG 215 (504 bytes, ~490 characters) or NTAG 216 (888 bytes, ~870 characters), or the use of a branded URL shortener (e.g., `go.brand.com/ABC123`) to compress the URL before encoding. Tracking query parameters (UTM codes, campaign identifiers) consume memory at the same rate as URL path characters and should be budgeted accordingly.
- Q: Do iPhones and Android phones both read NDEF records consistently?
  A: Both platforms read NDEF records from background tag reading, but there are behavioural differences. iPhone XS and later running iOS 14+ read NDEF tags in the background with the screen unlocked; older iPhones (iPhone 7 through iPhone X on iOS 13) require Apple's NFC Tag Reader from Control Center or a Core NFC app. Android phones with NFC enabled have supported background reading since Android 4.0 (2011). URI records route to the default browser on both platforms. Wi-Fi records are handled inconsistently on iOS (better on Android). vCard records open Contacts on both. For cross-platform programmes, test on iPhone XS, iPhone 14, Pixel 6 and Samsung S22 before mass deployment to confirm behaviour on the devices your audience uses.
- Q: What happens if a consumer tries to modify a tag after it leaves the factory?
  A: The outcome depends on the locking strategy. For tags locked with static NDEF lock (NTAG 213/215/216), any write attempt returns an error and the existing NDEF content is preserved. For tags with password protection, unauthorized write attempts fail and after AUTHLIM incorrect password attempts the tag permanently rejects further writes. For NTAG 424 DNA tags in SUN mode, an attacker cannot produce a valid CMAC without the AES-128 key, so a modified tag's backend verification fails and the server rejects the counterfeit. For high-assurance programmes (luxury goods, pharmaceuticals), NTAG 424 DNA with AES-128 SUN is the recommended choice; for consumer marketing where tamper resistance is less critical, NTAG 213 with static NDEF lock is cost-effective.
- Q: How do I choose between URL records and app-launch records (AAR) for my NFC programme?
  A: For cross-platform programmes (where iPhone and Android users must both have a good experience) use a URI record pointing to a Universal Link / App Link (an HTTPS URL registered to your app in both App Store Connect and Google Play Console). On iPhone with the app installed, the URL opens in the app; without the app, it opens in Safari. On Android the behaviour is symmetric via App Links. Adding an Android-specific AAR record alongside the URI record is redundant for modern programmes and complicates the NDEF message. AAR is useful only for Android-only programmes that specifically want to bypass the Play Store redirect behaviour.
- Q: Can I change the NDEF content on tags after they're in the field?
  A: For tags locked with static NDEF lock, no. The content is permanent. For tags with password protection, authorized rewriting is possible using a phone app or reader that knows the password; this is useful for campaign updates on retained physical tags. For NTAG 424 DNA tags, the URL template is fixed at production time but the SUN mirror dynamically injects authentication values per-read, so the effective URL changes on every tap without the tag being rewritten. Most production NFC programmes lock tags at production because the operational complexity of in-field rewriting exceeds the cost of issuing fresh tags for major campaign changes; use password protection only if your programme specifically requires in-field updates.
- Q: What is the difference between NDEF on NTAG 424 DNA versus NDEF on NTAG 216?
  A: NTAG 216 stores a single static NDEF message in its 888 bytes of user memory; whatever NDEF content is encoded is what every phone reads. NTAG 424 DNA has 416 bytes of total memory organized as an ISO/IEC 7816-4 file system: a 32-byte capability container (CC, file E103), a 256-byte NDEF file (E104) and a 128-byte protected data file (file 03). The NDEF capacity is therefore 256 bytes, not 416. The chip layers Secure Dynamic Messaging (SDM, also marketed as SUN — Secure Unique NFC) on top of the static NDEF file: the encoded URL template contains placeholder tokens that the chip replaces at read time with the current monotonic read counter, the tag UID and a cryptographic CMAC computed with the per-tag AES-128 key (or LRP-wrapped AES for stronger side-channel resistance, per NXP application note AN12196). The effective URL is dynamic per-read, which is the basis of clone detection and replay resistance. NTAG 216 is the right choice for large static payloads (long vCards with photos, multi-record messages, JSON blobs); NTAG 424 DNA is the right choice for authenticated URLs that a backend server can verify as coming from a genuine, non-cloned tag.
- Q: Has the NFC Forum NDEF specification been formally standardized at IEC?
  A: Yes. In March 2026 the NFC Forum announced that two of its core specifications — NDEF and Wireless Charging (WLC) — were formally adopted by the IEC as global standards. NDEF became IEC 63652-2:2026 and WLC became IEC 63652-1:2026. The IEC adoption does not change the technical content of the specifications; it elevates them from industry-association deliverables to formally balloted international standards under IEC governance, with the NFC Forum committing to liaise with IEC on future updates. For procurement and tender language that requires reference to a formal international standard (rather than to an industry-body specification), citing IEC 63652-2:2026 is now the technically preferred form. The NFC Forum continues to publish and license its source-of-truth NDEF Technical Specification in parallel for member access.

## Machine Routes
- JSON: https://proudtek.com/machine/guides/nfc-ndef-format-explained.json
- Text: https://proudtek.com/machine/guides/nfc-ndef-format-explained.txt