NTAG213 vs NTAG215 vs NTAG216 (and NTAG424 DNA): NFC Chips for Business

NTAG213, NTAG215 and NTAG216 are the same NFC chip family in three memory sizes: 144, 504 and 888 bytes of user memory. Pick NTAG213 for URLs and simple links, NTAG215 for vCards and multi-record messages, and NTAG216 for larger payloads such as detailed contact cards or device settings. For cryptographic tag authentication, NTAG 424 DNA adds AES-128 and configurable Secure Dynamic Messaging, with server-side validation.

NTAG213 vs NTAG215 vs NTAG216 vs NTAG 424 DNA at a glance

All four are NXP NTAG® chips on ISO/IEC 14443 Type A at 13.56 MHz, so compatible NFC phones can read correctly formatted NDEF records; test the required phone models and OS versions. The NTAG21x trio are NFC Forum Type 2 tags with identical command sets. NTAG 424 DNA is a Type 4 tag with a file system and real cryptography.

	NTAG213	NTAG215	NTAG216	NTAG 424 DNA
NFC Forum type	Type 2	Type 2	Type 2	Type 4
Protocol	ISO/IEC 14443-2/-3 Type A	ISO/IEC 14443-2/-3 Type A	ISO/IEC 14443-2/-3 Type A	ISO/IEC 14443-4 Type A, ISO/IEC 7816-4 commands
Total memory	180 bytes (45 pages)	540 bytes (135 pages)	924 bytes (231 pages)	File-based
User memory	144 bytes	504 bytes	888 bytes	416 bytes: 256-byte NDEF file, 128-byte proprietary file, 32-byte CC file
UID	7 bytes	7 bytes	7 bytes	7 bytes (random ID option)
Access protection	32-bit password	32-bit password	32-bit password	AES-128 mutual authentication, 5 keys
Tap counter	24-bit	24-bit	24-bit	24-bit, inside the SUN message
Per-tap URL data	UID and counter mirror (ASCII)	UID and counter mirror	UID and counter mirror	SDM: configurable UID/counter mirroring and CMAC, with optional encryption
Originality check	ECC signature	ECC signature	ECC signature	ECC signature
Relative chip cost	Lowest	Low	Low to moderate	Higher
Typical use	Links, menus, product info	vCards, multi-record messages	Larger configs, detailed vCards	Authenticated product links with a validating backend

The NTAG21x chips are rated for 100,000 write cycles and 10 years of data retention, plenty for tags written once or updated occasionally.

Memory and page table

Type 2 tags organize memory in 4-byte pages. The layout is the same on all three chips; only the size of the user area and the addresses of the configuration pages change.

Pages (hex)	NTAG213	NTAG215	NTAG216	Contents
UID and static lock	00h–02h	00h–02h	00h–02h	7-byte UID, check bytes, static lock bytes
Capability container	03h	03h	03h	CC (one-time programmable)
User memory	04h–27h	04h–81h	04h–E1h	NDEF data: 144 / 504 / 888 bytes
Dynamic lock bytes	28h	82h	E2h	Lock bits for user pages from 10h up
Configuration	29h–2Ah	83h–84h	E3h–E4h	Mirror settings, AUTH0, access bits, counter enable, retry limit
Password (PWD)	2Bh	85h	E5h	32-bit password, always reads as 00h
Password acknowledge (PACK)	2Ch	86h	E6h	16-bit value the tag returns on a correct password

Two details catch people out. First, the capability container declares the NDEF area in 8-byte units (12h, 3Eh and 6Dh), which is 144, 496 and 872 bytes. That is why some apps show slightly less than the raw user memory on NTAG215 and NTAG216. Second, the NDEF message is wrapped in a TLV block with an end marker, so the message itself gets a few bytes less than the declared area.

The UID is programmed at the factory and cannot be changed on genuine chips. The static and dynamic lock bits are one-way: once set, the pages they cover are permanently read-only.

How much data fits: URL, vCard, Wi-Fi and device configuration

NFC phones read NDEF (NFC Data Exchange Format) messages. Each record carries a few bytes of header, and URI records save space by compressing common prefixes: “https://www.” is stored as a single byte. Approximate sizes for common payloads:

Payload	Approx. NDEF size	NTAG213 (144 B)	NTAG215 (504 B)	NTAG216 (888 B)
Short URL, e.g. https://www.example.com/p/12345	≈ 30 bytes	Yes	Yes	Yes
URL with mirrored UID and counter (21 ASCII characters)	≈ 50–80 bytes	Yes	Yes	Yes
Long tracking URL, ≈ 130 characters after the prefix	≈ 140 bytes	At the limit	Yes	Yes
Wi-Fi credential record (SSID + WPA2 passphrase)	≈ 90–180 bytes	Typical lengths only	Yes	Yes
Basic vCard: name, company, phone, email, website	≈ 150–300 bytes	No	Yes	Yes
Detailed vCard: address, several numbers, notes	≈ 300–800 bytes	No	Low end only	Usually
vCard with embedded photo	Kilobytes	No	No	No

URLs. NTAG213 fits a URL of roughly 130 characters after the prefix. That covers product pages, menus, review links and support pages. If the destination may change, encode a short redirect URL you control and change the redirect, not the tag.

vCards. A plain contact card usually runs 150–300 bytes, which rules out NTAG213. NTAG215 is the common choice; NTAG216 gives headroom for addresses and notes. A photo does not fit on any of them. A popular alternative is an NTAG213 carrying a link to a hosted .vcf file or profile page, which you can update without re-encoding the tag.

Wi-Fi. An NFC Forum Wi-Fi credential record grows with the SSID and passphrase length. Typical home and guest networks fit NTAG213, but a long SSID combined with a long passphrase (up to 32 and 63 characters) does not. NTAG215 removes the doubt.

Device configuration. Commissioning data for meters, lighting drivers, controllers or IoT nodes is usually a MIME or NFC Forum external-type record, from tens to several hundred bytes. Size the chip for the largest version of the payload plus a margin. If the device itself must read or update the data over a wire, look at connected-tag chips with an I²C interface rather than a passive NTAG21x.

Multiple records add up: an Android Application Record, a Smart Poster title or a second URL each bring their own header and payload.

Password protection, counters and UID mirror

32-bit password. The AUTH0 byte sets the first page that needs a password, and the PROT bit chooses whether that range is protected against writes only, or against reads and writes. The reader sends the 32-bit PWD and gets the 16-bit PACK back, as a password acknowledgement; PACK does not provide cryptographic tag authentication. The password crosses the air in plain text, so treat it as protection against casual rewriting of public tags, not as cryptography. An optional retry limit (AUTHLIM) can permanently block password access after too many wrong attempts, so set it with care.

Permanent lock. For tags on posters, shelves or packaging, many projects simply write the message and set the lock bits. The locked pages remain readable and cannot be rewritten on that chip. This does not prevent someone from replacing the tag or copying its URL to another tag.

24-bit NFC counter. When enabled, the counter increments on the first read after each power-up in a reader field, which roughly equals one tap. An app can read it with the READ_CNT command, or the chip can mirror it into the URL.

UID and counter mirror. The chip can insert its UID (14 ASCII hex characters), its counter (6 characters) or both (21 characters with an “x” separator) into the NDEF message as it is read. You reserve placeholder characters in the URL, and each tap produces a link such as …?id=04A1B2C3D4E5F6x00002A. This lets the server log which tag was tapped and how often, with a single encoded URL for the whole batch.

Originality signature. Each chip stores an ECC signature over its UID that software can check against NXP’s public key to check the signed UID. A replayed UID and signature still need separate treatment; this is not a live cryptographic challenge-response.

The limit is the same for mirror, counter and signature: all three are predictable or static. Anyone who reads a tag can copy the URL pattern and fake the next counter value, and an emulator can replay the UID and signature. They give you uniqueness and analytics, not authenticity.

When to use NTAG 424 DNA for anti-counterfeiting

NTAG 424 DNA supports Secure Dynamic Messaging (SDM), which places authenticated data in an NDEF URL. UID and read-counter mirroring, encryption and the CMAC field depend on the chosen configuration; they are not all enabled automatically on every supplied tag. Configure customer keys and a backend that verifies the message and applies a counter policy before accepting it.

Rejecting repeated or stale counters helps detect replay of previously accepted URLs. That policy must handle genuine retry behavior too. A valid message establishes possession of data produced by the keyed tag; by itself it does not rule out a live relay, a message collected earlier, or a genuine tag moved to a different item.

The chip holds five customer-defined AES-128 keys and supports mutual authentication and encrypted, MAC-protected communication for apps that need more than a URL. It also offers a random-ID option for privacy and an optional LRP mode alongside standard AES.

Choose NTAG 424 DNA when:

• An authenticated product link is needed, paired with attachment and supply-chain controls.
• You need a stronger checkpoint record, paired with freshness controls and an assessment of live relay or pre-collected messages.
• Rewards or warranty claims require server-validated tag messages, with replay handling and clear acceptance rules.

Plan three things before you order. Keys: decide who generates and holds them, and use per-tag key diversification so one leaked tag does not expose the batch. Backend: SUN only works if a server validates every tap. Attachment: a genuine tag peeled off one bottle and stuck on another still validates, so pair it with tamper-evident labels or a chip variant with a tamper loop.

For door access, keep expectations realistic. An NTAG21x UID used as a credential is easy to emulate, and verifying SUN messages at a door needs a reader and controller built for it. For most secure door projects, MIFARE® DESFire® EV2/EV3 with an authenticating reader is still the conventional path; our MIFARE Classic vs DESFire guide explains why.

Form factors: cards, PCB, FPC, on-metal tags and wristbands

The chip sets memory and features; the antenna and housing set read range and durability. A phone reads a full-size card from a few centimeters, while a 10 mm tag may need near contact, so small tags need a clear “tap here” mark.

• ISO cards. CR80 cards (85.60 × 53.98 mm, 0.76 mm nominal thickness) have the largest antenna and the best phone range. They print well for membership, event and business cards.
• Stickers and labels. Dry or wet inlays with paper, PET or synthetic faces for packaging, posters and asset labels. Choose the adhesive for the surface and environment.
• Key fobs, epoxy tags and wristbands. Silicone and PVC bands suit leisure and gym use. Woven bands with single-use closures suit events. Fobs survive keyrings and pockets.
• PCB and FPC tags. Rigid PCB tags can be potted into equipment, while flexible FPC tags follow curved housings. Batteries, metal chassis and ground planes nearby detune the coil, so test in the final enclosure.
• On-metal tags. A plain NFC sticker on steel usually won’t answer. On-metal versions add a ferrite layer between coil and metal, and phones still read them only at short range. Our guide to RFID on metal explains why.

Bulk ordering: pre-encoding and printing

For runs of hundreds or thousands, encode and print at the supply stage instead of tapping tags one by one with a phone app. Decide these points before you ask for a quote:

• Data file. A CSV with one row per tag: the URL or record content, a serial number and the printed text or QR code. The same URL for every tag is simpler; a per-tag URL, or a single URL with UID mirror, lets you tell tags apart.
• Protection. Lock the tags permanently, set a password, or leave them open. Locking cannot be reversed, so approve a locked sample first.
• UID report. Ask for a file matching each UID to its serial number and printed number. You will need it for enrollment, analytics and support.
• Printing. Offset or digital CMYK for artwork, plus variable data such as numbers, QR codes and barcodes that match the encoded data. Specify finish, hole punch and label adhesive.
• Genuine chips. Confirm the exact chip on the quote and check the originality signature on samples with an NFC app.

We supply NFC cards, key fobs and embeddable PCB and FPC tags. Confirm the chip options for each form factor when you request a quote; printing, numbering and data writing can be arranged on request.

Checklist: before you order NTAG tags

• Payload type and largest size in bytes (URL, vCard, Wi-Fi, config)
• Chip: NTAG213, NTAG215, NTAG216 or NTAG 424 DNA
• Same data on every tag, per-tag data, or UID/counter mirror
• Lock permanently, password-protect, or leave rewritable
• For NTAG 424 DNA: key custody, diversification and backend validation
• Form factor, size in mm and mounting surface (metal, plastic, glass, fabric)
• Environment: outdoor, wash cycles, temperature range in °C
• Printing: artwork, variable data, finish, punch hole
• Phones and readers the tags must work with
• Sample quantity for testing and forecast volume

Next steps

Send us your payload, the chip you have in mind, the form factor and your quantity. We will confirm which chip fits the data, send samples for testing on your phones and readers, and quote pre-encoding and printing to your file. Request a quote or samples.

Sources and review scope

Reviewed 1 October 2026. Payload sizes in the examples are estimates; measure the encoded NDEF bytes before ordering.

• NXP: NTAG213, NTAG215 and NTAG216 — family features.
• NXP: NTAG21x data sheet — memory map, lock bits, password and counter behavior.
• NXP: NTAG 424 DNA data sheet — files, keys and configurable security modes.
• NXP AN12196: NTAG 424 DNA features and hints — SDM provisioning and backend verification examples.