NTAG215 vs NTAG213 vs NTAG216: How to Choose the Right NFC Chip
Aug 01, 2026
Leave a message
NTAG215 vs NTAG213 vs NTAG216: How to Choose the Right NFC Chip
A buyer sends over a specification for fifty thousand tags. The artwork is signed off, the die line is approved, the delivery window is fixed, and the chip line on the purchase order says "NTAG216, for future expansion." Nobody in the chain is doing anything careless. Six weeks later the tags arrive, they work perfectly, and the campaign writes a forty-character short link into a chip with 888 bytes of user memory. The order would have cost less on NTAG215, less again on NTAG213, and there is no version two of a chip.
The opposite version of that email is more expensive. A digital business card programme standardises on the cheapest part in the family, ships, and then the marketing team asks to append UTM parameters to every URL. The payload no longer fits. There is no software patch for a memory ceiling, and the only remedy is reissuing physical cards to people who already have one in their wallet.
Neither of those is the message we get most often, though. The most common one is shorter: the app said write successful, and the reader still does nothing. That one is an encoding problem and we have written about it separately. The two above are chip selection problems, and they are worse, because encoding can be repeated and a chip cannot.
All three come out of the same gap. The comparison content available on NTAG213, NTAG215 and NTAG216 stops at a memory table, and a memory table does not tell a buyer how many bytes their own payload consumes, what the specification sheet quietly leaves out, what a bulk order of custom NTAG215 tags is actually gated by, or how to prove at goods-in that the chip inside the laminate is the chip on the invoice.
What the Three Part Numbers Actually Share
Before the differences are worth discussing, it helps to establish how little separates these parts, because a surprising share of purchasing arguments are conducted over properties that are identical across all three.
NTAG213, NTAG215 and NTAG216 are one silicon family from the same manufacturer, released together and collectively referred to as NTAG21x. All three comply with the NFC Forum Type 2 Tag specification and with ISO/IEC 14443 Type A, they operate at 13.56 MHz, they transfer at 106 kbit/s, they carry a 7-byte serial number, and they carry the same ECC-based originality signature format. Their operating distance specification is the same figure, up to 100 mm, qualified in the data sheet as depending on field strength and antenna geometry (NXP NTAG213/215/216 product data sheet). Phone behaviour is identical too: every handset that reads one reads all three, and the Type 2 conformance that makes that true is defined by the standards body rather than by any chip vendor (NFC Forum).
The practical consequence is worth stating without hedging, because "it depends on your application" is the wrong answer here. Anyone selling you NTAG216 on grounds of speed, range, reliability, durability or phone compatibility is describing a difference that does not exist. Memory is the variable. Everything else is the same part.
The Memory Table, With the Column Everyone Omits
Comparisons of NTAG215 memory size against its two siblings almost always reproduce three numbers and stop. Those three numbers are correct, and they are also incomplete in a way that matters once you are budgeting a payload rather than browsing.
| NTAG213 | NTAG215 | NTAG216 | |
|---|---|---|---|
| Total EEPROM | 180 bytes | 540 bytes | 924 bytes |
| Pages (4 bytes each) | 45 | 135 | 231 |
| User read/write memory | 144 bytes | 504 bytes | 888 bytes |
| NDEF capacity declared in the capability container | 144 bytes | 496 bytes | 872 bytes |
| Dynamic lock coverage | 96 bytes | 456 bytes | 840 bytes |
| Lock granularity | 2 pages | 16 pages | 16 pages |
| Data retention | 10 years | 10 years | 10 years |
| Write endurance | 100,000 cycles | 100,000 cycles | 100,000 cycles |
Rows four and six are the ones worth pausing on, and both come from the same source as the headline figures.
The capability container is a four-byte structure the chip carries from the wafer, and its third byte declares to a reader how much NDEF space is available. On the mid-capacity part that byte declares 496 bytes against 504 bytes of user memory, and on the largest part it declares 872 against 888. The gap is small in absolute terms and consequential in practice, because a toolchain that derives the size of the data area from the capability container will compute the wrong boundary, and therefore locate the dynamic lock area and the configuration pages in the wrong place. Encoding software that has only ever been tested against the 144-byte part will not surface this, since on that part the two figures agree.
Whether that eight-byte discrepancy ever costs you anything depends on one condition, and it is worth knowing which side of it you are on. If your tags are encoded with a phone app or a stock desktop encoder writing a plain NDEF message, the software handles the offset and you will never see it. It bites when someone writes their own encoder, or ports an existing one from NTAG213 to NTAG215, and derives the configuration page address arithmetically from the capability container instead of from a part-number lookup. That is exactly what happens when a project moves up a memory tier mid-programme, which is the same moment everyone is least prepared to debug it.
While we are dealing in specification numbers, one correction is due. A scan-count ceiling of fifty thousand, two hundred thousand and five hundred thousand operations for the three parts circulates widely across tag retail sites and gets copied into buyer-facing comparisons every year. It does not appear in the manufacturer's data sheet, and it sits awkwardly beside the published endurance figure of 100,000 write cycles, which is the same for all three. Treat any supplier quoting that scan-count table as someone repeating the market rather than reading the source.
Budgeting Your Payload in Bytes Before You Commit to a Part
Here is the calculation that decides an NTAG215 bulk order, and almost nobody publishes it, because publishing it removes the ambiguity that makes over-specification easy to sell.
An NDEF message is not your URL. Before a single character of the address is stored, the chip's user area carries a TLV wrapper, then a record header, a type-length field, a payload-length field, and a type field. A URI record then compresses common prefixes such as https://www. into one byte, which hands ten to twenty of those bytes back. On a 144-byte part the arithmetic is tight enough that the compression is often the difference between a payload that fits and an overflow error at the encoder.
What consumes the remaining headroom is rarely the URL. It is the extras. A second text record carrying a human-readable label, an Android Application Record so the tap opens an application rather than a browser, a serial number appended per unit, tracking parameters added when the campaign is handed to an agency: each of these draws on the same budget, and each tends to be requested after the hardware decision is frozen.
| Payload | Realistic budget | Smallest part that holds it |
|---|---|---|
| Short link, no parameters | 30–60 bytes | NTAG213 |
| Full URL with query string and UTM parameters | 100–160 bytes | NTAG215 |
| URL plus text record plus application record | 150–250 bytes | NTAG215 |
| Complete vCard with address and two phone numbers | 350–500 bytes | NTAG215 |
| Wi-Fi credentials plus a provisioning URL plus a device identifier | 200–400 bytes | NTAG215 |
| Multi-record payload with several localised text records | 500 bytes and up | NTAG216 |
Our own working threshold, and this is the sort of rule that only comes out of encoding volume rather than out of a data sheet, is around ninety characters. If the intended URL including every parameter you can foresee exceeds roughly ninety characters, stop specifying the 144-byte part and move up a step; the per-unit difference between the two is small enough that it is almost never worth carrying a redesign risk through a programme. That threshold is deliberately conservative, and the reason is that it is not really a byte calculation. It is a forecast of how much a URL will grow over the tag's service life, and that forecast depends on things this article cannot see, including whether serialisation is sequential or random and whether an agency will later own the destination. The mechanics of writing those bytes, including the three separate operations that a phone app collapses into one button, are covered in our companion notes on programming NFC tags across different chip families.
When Specifying Down from NTAG215 to NTAG213 Is the Better Call
The default assumption in this category runs one direction. More memory reads as more headroom, headroom reads as safety, and the incremental cost per unit is small, so buyers drift upward. There is a real argument on the other side, and it deserves more than a footnote.
A tag can be a data container or it can be a pointer. When it is a pointer, the only thing living in user memory is an address, the actual content sits on a server you control, and you can change that content on a Tuesday afternoon without touching a single unit in the field. When it is a container, the content is in the laminate, and changing it means either a rewrite pass over every physical tag or a reissue. Across our order history the most frequent post-delivery request is not a defect claim at all: it is a destination change, and it clusters inside the first year of service, usually triggered by a landing page migration or an agency handover. Every one of those requests is cheap to satisfy on a pointer architecture and expensive on a container architecture, regardless of which part number is inside.
That reframes the comparison. If your architecture points rather than stores, the 144-byte part is not a compromise, it is the correct specification, and the mid-capacity part is a purchase of insurance against a risk your design has already eliminated. The 144-byte part ships in the highest volume of the family for exactly this reason.
The counter-argument buyers reach for is the price ratio, and it is a genuinely good one: moving up a tier buys roughly three and a half times the user memory for a premium measured in fractions of a cent at volume. Judged as a hedge, that is cheap insurance. Judged as a line item, it is also the only part of the decision that is reversible in the sense that matters, because you can always specify down on the next order and you can never specify up on the current one.
Where the argument reverses is a payload that has to survive without connectivity. Configuration data read by an offline reader, credentials consumed by an embedded system with no backend, a maintenance record that has to be legible at a site with no signal: in those deployments the tag genuinely is the database, and NTAG215 user memory becomes the floor rather than the ceiling. The question to put to your own design is not how many bytes you need today. It is whether a network is available at the moment of the tap, and that is worth settling on paper before the purchase order rather than discovering at the first field trial.
Passwords, Lock Granularity and the Limits That Never Reach the Spec Sheet
Four constraints on this family are documented but rarely surfaced during selection, and each one has closed off a design after the purchase order was signed.
The first concerns protection. All three parts offer a 32-bit password with a 16-bit acknowledgement, and the word "password" does a lot of unearned work in supplier literature. The value is transmitted in the clear and checked by the chip, gating write access and optionally read access from a page you nominate. That stops a member of the public rewriting a public-facing tag with a phone, which is a real and useful thing. It is not a cryptographic control, it does not resist a determined attacker, and it should never appear in a specification document next to the word "secure". Applications making an authenticity claim to an end customer need an AES-based part, not NTAG215 password protection with an optimistic description attached.
Second, and this produces the most counter-intuitive result in the family, comes lock granularity. Locking on these chips is not one switch. Three dynamic lock bytes cover a defined slice of the data area, and the smallest region each bit controls differs by part: two pages on the 144-byte chip, sixteen pages on the two larger ones. Sixteen pages is sixty-four bytes. So a mixed layout on NTAG215, with a serialised region frozen at the factory and a campaign region left writable, is viable but coarse, and the boundary between the two has to land on a sixty-four-byte line. A design that needs a small locked field adjacent to a small writable field is easier on the smaller chip, which is precisely the opposite of what buyers expect when they move up for flexibility.
Industry practice supplies the third constraint, and it is procedural rather than technical. The application note the data sheet points to for correct use of those dynamic lock bits is not a public document; it requires an agreement with the manufacturer and access to their restricted document store, a limitation confirmed by their own engineers in the vendor forum (NXP Community). Whether locking can be executed correctly on your batch is therefore partly a question about your supplier's channel, not only about the silicon. Worth asking before the order rather than after.
The fourth produces scrapped inventory rather than a blocked design. Anti-tearing protection on NTAG21x, described in the manufacturer's own application note AN13089, covers the OTP area, the lock bits and the counters. It does not cover user data pages. If a tag leaves the RF field partway through a user-memory write, which is routine on a moving production line or in the hand of a warehouse operator working quickly, the chip guarantees nothing about what is left behind. Protecting user data against a tear-off is an application-layer responsibility, and any encoding process that writes without reading back has quietly declined that responsibility. This is one of the reasons an in-line verification pass is not optional above a few thousand units.
Proving the Batch Really Contains Genuine NTAG215 Chips
This is the risk buyers rank lowest and should rank second. A tag that reads correctly on a phone tells you almost nothing about which silicon is inside, and substitution in this category is documented rather than hypothetical: engineers who bought a range of NTAG21x tags through general retail channels reported to the manufacturer's own community that every sample behaved exactly to specification, counter mirroring included, while the originality check returned an unverifiable signature and identified the parts as clone silicon. The manufacturer's published response was that such products are unsupported and should not be relied on for secure use, because the IC itself may be vulnerable (NXP Community).
Three checks make up a workable incoming procedure, and they run in about a minute per sample.
Start with the version response. The chip will report its storage size, but it reports it as a range rather than a value: the 144-byte part falls between 128 and 256, the 504-byte part between 256 and 512, the 888-byte part between 512 and 1024. A single read therefore narrows the identification without completing it, and the response has to be resolved against a lookup table. Reading the version once and concluding "this batch is genuine NTAG215" is the most common shortcut in goods-in, and it is not a conclusion the response supports.
Then verify the originality signature. Every genuine part in this family carries a 32-byte ECDSA signature over its UID, written at chip production and readable through a dedicated command, which can be checked against the manufacturer's published public key. A part that fails this check is not from the fab it claims. Understand what a pass proves, though, because this is where the check is routinely oversold: a valid signature establishes that the silicon is genuine, not that the finished product is. Genuine silicon can be recovered and rehoused, and the UID and the signature are both readable, so the check is an authenticity gate on the chip and not a tamper seal on the tag.
Finish by writing to and reading back the full user area. This is the only step that actually confirms capacity, and it is the one that catches the substitution buyers most often worry about, a smaller part invoiced as a larger one. If 504 bytes go in and 504 bytes come back, the question is settled.
Whether you can run that third check on every unit rather than on a sample is a question about the supplier's line, not about your QC department. On ours it sits between chip bonding and final assembly across five production lines in a 3,600 m² plant, with automated bonding capacity above 100,000 chips per day, which is what makes 100% read-back affordable rather than a sampling exercise; a unit that fails is rejected before it reaches packing, and the batch ships with a mapping file linking each UID to the content written to it. For the adjacent failure mode, where a write reports success and the reader still does nothing, our notes on why a cloned sticker reads fine and still fails at the door cover the diagnostic sequence.
What the three checks cannot tell you is where to set the acceptance threshold, and that number is genuinely build-specific. An anti-metal sticker, a printed PVC card and a laminated wristband do not behave the same way through the same encoding line, and a defensible reject rate for one is a red flag for another.
Read Range Is an Antenna Question, Not a Part Number Question
A recurring request arrives after a field trial disappoints: the tags read at fifteen millimetres, we need thirty, please quote the same item on NTAG216. The upgrade will not deliver it. All three parts carry the same operating distance specification, and that specification is written as a conditional statement about field strength and antenna geometry rather than as a property of the chip.
Coupling is governed by the tag antenna's enclosed area and turn count, by what the tag is mounted on, and by the reader's own field. In our own sampling we routinely build the same NTAG215 die into a 25 mm circular label and into a CR80 card inlay for the same customer, and the two formats do not read alike: the card antenna encloses several times the area of the label antenna, and range follows that ratio far more closely than it follows anything on the data sheet. Between the three part numbers, meanwhile, the difference is zero. Metal behind the tag detunes the antenna and collapses the range regardless of which chip is bonded to it, which is what the ferrite layer in an anti-metal construction exists to address.
The consequence for specification writing is simple enough. Read range belongs in the form factor conversation, alongside label diameter, substrate and mounting surface, and it should be validated on the reader estate that will actually be deployed. It does not belong in the chip conversation at all, and a supplier who responds to a range complaint by proposing a larger part number is either not listening or not reading. If the format is still open, the sticker and label formats we build custom NTAG215 tags into are the practical place to start that conversation.
Matching the Part to the Deployment
Everything above collapses into one question with three inputs: how many bytes the payload needs, whether a network is present at the tap, and whether the application makes a security claim.
| Deployment | Specify | Reasoning |
|---|---|---|
| Marketing redirect, poster or packaging | NTAG213 | Short link, network present, no authenticity claim. NTAG215 headroom here is unused cost |
| Digital business card | NTAG215 | vCard payloads and future parameters overrun 144 bytes, and the card format matters more than the chip |
| Event credential or membership card | NTAG215 | Serialised URL plus a locked identifier region, and the 16-page lock boundary is workable at NTAG215 capacity |
| Offline device pairing or configuration | NTAG215 | The tag is the database because no backend is reachable at the tap |
| Multi-language or multi-record content on one tag | NTAG216 | Several records in parallel is the one case where 888 bytes is genuinely consumed |
| Product authentication with a claim to end customers | NTAG 424 DNA, not NTAG21x | A 32-bit password is access control; this needs AES authentication and dynamic messaging |
The last row is the one worth defending explicitly, because it is where the family is most often misapplied. Specifying NTAG215 for product authentication produces a bill of materials that survives a procurement review and fails a security review. If your packaging tells a consumer that a tap proves the item is genuine, the chip has to authenticate cryptographically and produce a message your backend can verify as fresh; NTAG 424 DNA does that with customer-held AES keys and a per-tap dynamic URL, and it is a different silicon class with a different budget. Discovering that requirement after tooling is the most expensive version of this whole discussion, and the key management it brings with it is covered in the companion article linked above.
For the card and credential end of that table, the substrate decision usually lands before the chip decision, and blank white PVC cards are where most digital business card programmes start.
What Actually Sets the Minimum Order for NTAG215 Tags
One question decides whether any of the above is actionable, and it is the one comparison articles never answer: what does an NTAG215 bulk order minimum quantity actually depend on?
Not the chip. Chips in this family are commodity silicon bought on reel, and the three part numbers have effectively the same procurement floor. The minimum is set by the converting step: the antenna etch or print, the die bonding, the lamination, and above all the tooling for the finished format. A round label running on an existing die needs no new tooling and carries a low floor. A custom-shape epoxy tag, a printed card with a bespoke layout, or an anti-metal construction with a ferrite layer each add a tooling gate, and the floor moves with it. Two orders for the same NTAG215 chip can therefore sit an order of magnitude apart on minimum quantity purely because one reuses tooling and the other does not.
The practical consequence for a buyer is that asking "what is your MOQ" produces a useless answer until the format is named, and that the fastest way to lower a minimum is usually to accept a stock format rather than to negotiate. Lead time behaves the same way and for the same reason. Where exactly your build sits depends on the format, the print process and whether encoding and serialisation are in scope, which is a quote rather than an article.
If a specification is already drafted, we will review it against the constraints above and flag what will not survive production, and free samples are available so the decision can be tested on your own readers and handsets rather than on ours. The formats we pre-program and verify in-house are listed under our NFC tag range, and if the payload structure and volume are already fixed you can send them over for a chip and encoding review.
FAQ
How much data can an NTAG215 actually hold?
504 bytes of user memory, of which the capability container declares 496 bytes as NDEF capacity, and the NDEF wrapper consumes part of that before your content is stored.
Can I upgrade from NTAG213 to NTAG215 after deployment?
No. The chip is fixed at manufacture, so the options are compressing the payload, moving the data server-side, or reissuing the tags at the next refresh cycle.
Do NTAG213, NTAG215 and NTAG216 have different read ranges?
No. All three carry the same operating distance specification, and actual range is determined by antenna size, substrate and mounting surface.
How do I verify that a batch really contains NTAG215 chips?
Resolve the version response against a lookup table, verify the ECC originality signature against the manufacturer's public key, then write and read back the full user memory to confirm capacity.
Is NTAG215 password protection sufficient for product authentication?
No. The 32-bit password is an access control that gates writing and optionally reading, and applications making an authenticity claim need NTAG 424 DNA or another AES-based part.
What sets the minimum order quantity for NTAG215 tags?
The converting and tooling step, not the chip. Stock formats carry a low floor; custom shapes, bespoke print layouts and anti-metal constructions each add a tooling gate that raises it.
Sources
- NXP Semiconductors, NTAG213/215/216 - NFC Forum Type 2 Tag compliant IC with 144/504/888 bytes user memory, product data sheet Rev. 3.2. Authority for user memory, EEPROM organisation, capability container values, dynamic lock coverage and granularity, data retention, write endurance, operating distance and originality signature. https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf - accessed 1 August 2026
- NFC Forum, Specifications and Technical Documents. Authority for NFC Forum Type 2 Tag conformance. https://nfc-forum.org/build/specifications - accessed 1 August 2026
- NXP Community, Where can I find AN11456? Vendor confirmation that the dynamic lock bit application note is not publicly available. https://community.nxp.com/t5/NFC/Where-can-I-find-AN11456/m-p/482503 - accessed 1 August 2026
- NXP Community, Counterfeit NTAG21x ICs in retail NFC tags? Field reports of fully functional retail tags failing originality verification, with the vendor's published position. https://community.nxp.com/t5/NFC/Counterfeit-NTAG21x-ICs-in-retail-NFC-tags/td-p/1724220 - accessed 1 August 2026
- NXP Semiconductors, application note AN13089, NTAG 21x features and hints, Rev. 1.0. Authority for the scope of anti-tearing protection. Document reference only; distribution is via the vendor's own channels.
Send Inquiry