How NDEF records are sized
The number of characters you type is not what a tag stores. Three layers set the byte count: the TLV wrapper that tells the reader where the message starts, the header of each record, and the payload, which a URI record compresses. Here is the complete bill for https://www.example.com on an NTAG213:
| Part | Bytes (hex) | Count |
|---|---|---|
| NDEF TLV tag | 03 | 1 |
| TLV length (1 byte) · 16 bytes | 10 | 1 |
| Record header · MB + ME + SR; TNF 1 (NFC Forum well-known type) | D1 | 1 |
| Type length · 1 byte | 01 | 1 |
| Payload length (short record: 1 byte) · 12 bytes | 0C | 1 |
| Type · “U” | 55 | 1 |
| URI identifier code · stands for “https://www.” | 02 | 1 |
| Rest of the URI (UTF-8) · “example.com” | 65 78 61 6D 70 6C 65 2E 63 6F 6D | 11 |
| Terminator TLV · left out when the message fills the tag | FE | 1 |
| Total on the tag | 19 | |
The TLV wrapper
NTAG213, NTAG215 and NTAG216 are NFC Forum Type 2 tags. They keep the message in a TLV block in the data area, which starts at page 4: a tag byte 03 (“an NDEF message follows”), a length and the message, then a single FE terminator byte when there is room after the message. On NTAG213 the factory Lock Control TLV comes first, so the NDEF TLV starts at page 5, byte 1. Up to 254 bytes the length takes one byte, so the wrapper costs 2 bytes, plus the terminator. From 255 bytes the length switches to a 3-byte form (FF plus two bytes) and the wrapper costs 4, plus the terminator. A message that fills the tag to its last byte is written without the terminator (NFC Forum Type 2 Tag Operation 1.1). NTAG 424 DNA is a Type 4 tag and has no TLV: its NDEF file starts with a 2-byte message length instead.
The record header and the short-record flag
Every record starts with a header byte that holds its flags and its Type Name Format (TNF). MB and ME mark the first and last record of the message; SR, the short-record flag, says the payload length fits in one byte. Then come the type length, the payload length and the type itself: U for a URI, T for text, text/vcard for a contact. A short URI or Text record therefore spends 4 bytes before its payload. When the payload passes 255 bytes the SR flag is cleared and the payload length takes 4 bytes, so the header grows by 3.
URI prefix compression
A URI record replaces a common prefix with a one-byte identifier code: 02 stands for https://www. (12 characters), 04 for https://, 05 for tel: and 06 for mailto:. Schemes without a code, such as sms:, are stored in full after a 00 code. For a web address the arithmetic is simple: the NDEF message is the characters after the prefix plus 5 bytes, and on an NTAG21x the TLV adds 2 more, plus the terminator when there is room, for addresses of up to 249 characters after the prefix. That is why an NTAG213, with 139 bytes for the TLV, holds 132 characters after https://www., and why long tracking parameters, not the domain, are what usually push a link onto a bigger chip.
Text and vCard records
A Text record puts a status byte and the language code (2 bytes for en, 5 for en-US) in front of the text, and every character outside ASCII takes 2 to 4 bytes in UTF-8. A vCard is stored as a MIME record whose type, text/vcard, costs 10 bytes, and the vCard itself is wordy: the BEGIN, VERSION, N, FN and END lines take about 50 bytes plus the name, which appears twice. Each line ends in two bytes (CR LF), and a line longer than 75 bytes is folded onto the next, which adds 3 bytes per fold (RFC 2426, RFC 2425 §5.8.1). A full business card often outgrows an NTAG213.
Chip capacities and where they come from
The checker compares the bytes above with the NDEF space each chip declares, not with its headline memory figure:
| Chip | User memory | Space for NDEF | Largest NDEF message | Why the difference |
|---|---|---|---|---|
| NTAG213 | 144 bytes | 139 bytes | 137 bytes | 144-byte NDEF area minus the 5-byte Lock Control TLV written at the factory (§8.5.4 Table 4, §8.5.6 Table 5) |
| NTAG215 | 504 bytes | 496 bytes | 492 bytes | NDEF area declared in the capability container (3Eh × 8) (§8.5.4 Table 4, §8.5.6 Table 6) |
| NTAG216 | 888 bytes | 872 bytes | 868 bytes | NDEF area declared in the capability container (6Dh × 8) (§8.5.4 Table 4, §8.5.6 Table 7) |
| NTAG 424 DNA | 416 bytes | 256 bytes | 254 bytes | 256-byte NDEF file; its first 2 bytes hold the message length (§8.2 file structure) |
NTAG21x figures are from the NXP NTAG213/215/216 data sheet: user memory in §8.5.5, the NDEF area declared in the capability container in §8.5.4 (Table 4), and the memory content at delivery in §8.5.6 (Tables 5 to 7). NTAG 424 DNA figures are from the NXP NTAG 424 DNA data sheet (§8.2: a 32-byte capability container file, a 256-byte NDEF file and a 128-byte proprietary file) and NXP application note AN12196 (§5.7, the 2-byte NDEF length).
The largest message is the NDEF space less the TLV tag and length (2 bytes, or 4 from 255 bytes) on NTAG21x, and less the 2-byte length on NTAG 424 DNA. The checker counts the whole NDEF TLV, adds the terminator whenever there is room for it, and assumes the factory memory layout: a tag that holds other TLVs or was formatted by another tool can have less room. Planning SUN messages on NTAG 424 DNA? The mirrored UID, counter and signature are written into placeholder characters inside the URL, so measure the URL with its placeholders. Chip figures describe the silicon; the finished label or card is confirmed on samples.
To compare NTAG213, NTAG215 and NTAG216 side by side and choose one for a link, a vCard or several records, see NTAG213 vs NTAG215 vs NTAG216.
What phones do with each record
Fitting on the chip is half the job. The record type decides what happens when a phone reads the tag without an app open:
| Record | iPhone XS and later (background reading) | Android |
|---|---|---|
| Web address (http, https) | Supported: the system uses the first URI record in the message, which must hold a universal link or a supported scheme | Dispatched as a URI to the browser or the app that handles the link |
| tel:, mailto:, sms: | Supported URL schemes | Dispatched as a URI to an app that handles the scheme |
| Text | Not acted on: background reading looks only for URI records | Dispatched as the MIME type text/plain; the result depends on the apps installed |
| Contact (vCard) | Not opened: it is a MIME record, not a URI record | Dispatched by its MIME type, text/vcard; Android’s open-source Contacts app registers an import screen for it |
Sources: Apple, Adding support for background tag reading; Android, NFC basics (tag dispatch and the TNF and RTD mappings); the Android Contacts app manifest (text/vcard and text/x-vcard). Phone makers ship their own contacts apps, so test a vCard tag on the Android phones you target.
A contact card for iPhone users: host the vCard as a .vcf file on your own website, served as text/vcard (RFC 6350 §10.1), and encode its https address as a URL record. Every phone opens the link; the browser then hands the file to the contacts app or offers it as a download, depending on the phone and browser, so test it on the phones your recipients use. A hosted card can also be updated without re-encoding the tag.