NTAG213 vs NTAG215 vs NTAG216: Memory, URL Length and Which to Choose

The short answer

Choose NTAG213 when the tag stores a link, which covers most projects: its 144 bytes hold a web address of up to 132 characters after https://www., and a short URL on your own domain can redirect anywhere. Choose NTAG215 (504 bytes) for a vCard kept on the chip, several records or a long URL, and NTAG216 (888 bytes) when that data runs past NTAG215's 492-byte NDEF limit. When each tap needs cryptographic verification, none of the three is enough: use NTAG 424 DNA.

NTAG216 has the most memory of the NTAG21x chips: 888 bytes of user memory, of which an NDEF message can use up to 868 bytes as delivered. NTAG213 holds 132 URL characters after https://www., or 130 characters of plain English text.

The chip figures below come from NXP's NTAG213/215/216 data sheet (Rev. 3.2), the capacity rules from the NFC Forum Type 2 Tag specification (version 1.1), and phone behaviour from Apple and Android developer documentation. They describe the chips. A finished label's read distance and durability depend on its antenna, materials and surface, and are confirmed on samples.

NTAG213, NTAG215 and NTAG216 side by side

Memory size, and the page addresses and lock granularity that follow from it, are the only differences; the last row sums up what is identical, set out in full further down. Chip values are from the data sheet (sections 2 and 8 to 10); the NDEF and URL rows are worked out in the next two sections.

Check these options against your system →

How much NDEF data fits: the TLV arithmetic

A phone does not use the user memory as one block. Under the Type 2 Tag specification, byte 2 of the capability container (page 3) declares the NDEF data area as its value × 8 bytes, and the NDEF message sits inside a TLV block in that area: a tag byte (03h), a length field and the message. The length field takes one byte for messages up to 254 bytes and three bytes (FFh plus two) from 255 bytes. A terminator TLV (FEh) follows the message only when space remains; version 1.1 of the specification leaves it out when the NDEF TLV ends at the last byte of the data area, so it does not reduce the maximum.

NXP ships the chips already formatted (data sheet section 8.5.6). User memory starts at page 4. On NTAG213 a 5-byte Lock Control TLV (01 03 A0 0C 34) fills page 4 and the first byte of page 5, so the empty NDEF TLV (03 00 FE) starts at page 5, byte 1. NTAG215 and NTAG216 start directly with the empty NDEF TLV at page 4, and their capability containers declare 496 and 872 bytes, 8 and 16 bytes less than their user memory (Table 4). The arithmetic:

Check these options against your system →

How many characters fit: URL length per chip

A web address is stored as an NFC Forum URI record, record type U (NFC Forum NDEF and URI record specifications). The first byte of its payload is an identifier code that stands for a common prefix, so the prefix costs one byte however long it is: 01h means http://www., 02h https://www., 03h http:// and 04h https://. The rest of the address follows as text.

The record header adds 4 bytes when the payload is 255 bytes or less (a header byte, a type-length byte, a one-byte payload length and the type U) and 7 bytes above that, where the payload length takes four bytes. Subtract the header and the identifier code from the largest NDEF message:

• NTAG213: 137 − 4 − 1 = 132 characters after https://www., a 144-character address in full. An address without www. gets the same 132 characters after https://.
• NTAG215: 492 − 7 − 1 = 484 characters after https://www.
• NTAG216: 868 − 7 − 1 = 860 characters after https://www.
• Plain text instead of a URL: a Text record also stores a status byte and a language code such as en, so NTAG213 holds 130 single-byte characters (137 − 4 − 1 − 2), NTAG215 482 and NTAG216 858. Accented and non-Latin characters take two to four bytes each in UTF-8.
• In practice, leave headroom. Tracking parameters, a UID mirror (14 characters) or a UID-and-counter mirror (21 characters) all count as URL characters. A short path on your own domain that redirects on the server fits NTAG213 comfortably and lets you change the destination without re-encoding the tags.

What is identical on all three

Security and data-integrity features do not scale with memory. Each chip has the same set (data sheet sections 8.5 to 8.9):

• 7-byte UID. Programmed and write-protected by NXP during production test, starting with NXP's manufacturer code 04h, and used for ISO/IEC 14443-3 anticollision.
• 32-bit password. A 32-bit PWD and a 16-bit PACK protect memory from the page set in AUTH0 (FFh, meaning off, at delivery). PROT chooses write-only or read-and-write protection, and AUTHLIM can permanently block the protected access after 1 to 7 failed attempts. NXP presents the password as a convenient guard against unauthorised memory access and points to cryptography at application level where more protection is needed (section 8.8).
• NFC counter. A 24-bit counter, off at delivery. Once enabled, it increases on the first READ or FAST_READ after the tag is powered by a field and stops at FFFFFFh. It is read with READ_CNT or mirrored into the URL, and reading it can be password-protected (sections 8.6 and 10.6).
• UID and counter mirror. The chip can insert its UID (14 ASCII characters), its counter (6) or both with an x between them (21) into the NDEF message as it is read, so one encoded URL template returns a different URL from every tag (section 8.7).
• Originality signature. A 32-byte ECC signature over the UID (curve secp128r1, ECDSA), written in production and unchangeable, read with READ_SIG and checked against NXP's public key. NXP describes it as confirming with a certain confidence that the chip is NXP silicon; it does not authenticate the URL or the product (sections 8.9 and 10.8).
• Retention and endurance. 10 years' data retention and 100,000 write cycles, both specified at 22 °C, with tearing-protected writes to the capability container and lock bits.

Readers and phones treat them alike

All three use ISO/IEC 14443 Type A at 106 kbit/s and comply with NFC Forum Type 2 Tag. They answer anticollision with the same ATQA (0044h) and SAK (00h), so a reader tells them apart with GET_VERSION, whose storage-size byte is 0Fh, 11h or 13h (section 10.1). Encoding software must then use that chip's memory bounds and configuration pages; for the NTAG215/216 dynamic lock bits, NXP refers to its application note AN11456.

Android: devices with NFC must support NDEF on NFC Forum Type 1 to 4 tags (Android Ndef) and usually look for tags while the screen is unlocked. From Android 16 a web-link tag opens as an ordinary link, and Android 17 first shows an open-link notification (Android NFC basics).

iPhone: apps read NDEF on tag types 1 to 5 through Core NFC. iPhone XS and later also read tags in the background, acting on the first URI record, which must hold a universal link or a supported scheme such as https, mailto or tel (Apple). A vCard stored on the chip is not a URI record, so on iPhone it needs an app; a link to a hosted contact page opens from the notification.

The chip therefore does not decide phone compatibility; the record type and the label antenna do. NXP gives all three the same 50 pF input capacitance and an operating distance of up to 100 mm depending on field strength and antenna geometry. A finished label's distance is set by its antenna, the phone and the surface, and is checked on samples.

Which to choose for URLs, vCards, larger payloads and counters

Start from the encoded record, not the visible text, and pick the smallest chip that holds it with headroom.

• URL or product link: NTAG213. Up to 132 characters after https://www. A review-card, packaging or profile link on your own domain is usually far shorter.
• URL with a per-tag serial or tap count: NTAG213, unless the address is long. The UID mirror adds 14 characters and the counter 6; count them in the URL.
• vCard on the chip: usually NTAG215. Name, one phone and one email come to about 105 bytes of vCard text; with a 13-byte MIME record header (type text/vcard) that is about 118 bytes, inside NTAG213's 137 with little to spare. Add a company, job title, website and postal address and it passes 230 bytes: NTAG215. Several numbers, addresses or notes can approach 500 bytes: NTAG216. A photo is normally several kilobytes, beyond all three, so link to it. For iPhone users a link to a hosted contact page is the more reliable tap; see NFC business cards.
• Several records or offline data: NTAG215 or NTAG216. A URL plus a text record, Wi-Fi credentials plus a link, or instructions that must work without a network: size the complete message against 492 or 868 bytes. Beyond that, store a link and keep the data on a server.
• Counting taps: any of the three. The counter is identical, so memory decides. If the count must be cryptographically verifiable, choose NTAG 424 DNA (next section).
• Frequent rewriting: any of the three. Each is specified for 100,000 write cycles.

How NTAG 424 DNA differs

NTAG21x can put its UID and counter into the URL, but as plain text: copy the URL, or the tag's bytes onto another tag, and the copy reads the same. NTAG 424 DNA is a different chip: an NFC Forum Type 4 Tag on ISO/IEC 14443-4 with AES-128 keys and 416 bytes of user memory, including a 256-byte NDEF file (NXP NT4H2421Gx data sheet).

Its Secure Dynamic Messaging produces what NXP calls SUN (Secure Unique NFC) authentication: when configured, each tap mirrors UID and counter data, which can be encrypted, and an AES-CMAC into the URL, and your verification server recomputes the code with the tag's key and rejects counters it has already seen. NXP notes that a message captured but never submitted can still pass a later check (section 9.3), so the integrator sets the verification policy. The chip needs personalisation, key management and a verification service; NTAG21x needs none of these.

Check these options against your system →

What Proud Tek supplies

Proud Tek has manufactured RFID and NFC products in Shenzhen since 2008. NTAG213 is the standard chip in our NFC labels and NFC cards; NTAG215, NTAG216 and NTAG 424 DNA are available on request, with the chip and construction confirmed per order in the quotation. We can deliver labels and cards encoded with a fixed URL, a per-piece URL list or a vCard, with the password protection or lock settings you specify: describe the scheme in your inquiry and hand over the password itself separately, on agreed terms. What is included is agreed in the quotation; our encoding service page explains how encoding works.

Send the exact record or URL with any tracking parameters, whether each piece differs, the label or card size, the surface it is fixed to, the target phones and the quantity. We match the chip to the measured record and send samples for your test.