NDEF Capacity Calculator
Live check: does your URL / text / vCard / Wi-Fi payload fit on your chosen NFC chip? NDEF framing and URI-prefix compression are applied.
Prefix https:// compressed to 1 byte (code 0x04). Remainder stored: roxtron.com/rfid
How this calculator works
Every NFC tag stores your payload wrapped in an NDEF (NFC Data Exchange Format) message. The tag chip's raw user memory — say 144 bytes on an NTAG213 or 888 bytes on an NTAG216 — is what the datasheet publishes, but the useful payload capacity is always smaller because NDEF adds framing. That framing is a Message TLV (Type + Length + Value) plus one or more NDEF records, each with its own header (flags byte + type length + payload length + record type). A short URL record adds about 7 bytes of overhead; a MIME record like vCard or Wi-Fi credentials adds more, because the MIME type string is stored in the record header. URLs get one useful optimisation: the NFC Forum URI Record Type Definition defines a table of 35 common prefixes ("https://www.", "tel:", "mailto:", ...). When your URL begins with one of them, a single byte replaces the whole prefix, letting an NTAG213 hold a URL of roughly 130 characters instead of the 137 raw bytes you'd expect. This calculator applies the actual TLV + record header formula from the NFC Forum Type 2/4/5 tag specs and NXP's application note AN1305, so the "bytes remaining" figure matches what a real phone will write.
URI prefix table
If your URL starts with one of these strings, a single byte replaces the whole prefix.
FAQ
Why is the usable NDEF capacity smaller than the datasheet's user memory?
The datasheet reports raw user memory. NDEF wraps every message in a TLV + record header (typically 7-15 bytes) and reserves 1 byte for a terminator. This calculator subtracts that framing.
How does URI-prefix compression work?
The NFC Forum URI RTD defines 35 well-known prefixes. If your URL starts with one — https://www., https://, tel:, mailto:, etc. — a single byte identifies the prefix and only the remainder is stored.
Why do vCard and Wi-Fi records take more overhead?
They are MIME records — the record header includes a full type string ('text/vcard' or 'application/vnd.wfa.wsc'), which costs 10-30 extra bytes vs a URL record.
Which chips are supported here?
Only NFC/HF/ISO 15693 tag ICs whose user-memory size is unambiguously published by the manufacturer. UHF chips do not use NDEF and are excluded.