NTAG21x Family

Chip family and part numbers

If you have tapped your phone on a restaurant table tent, scanned an event wristband, or touched the back of someone's NFC business card in the last few years, you have almost certainly powered an NTAG21x without ever learning its name. It is the chip nobody asks for by name and almost everybody ends up shipping. NXP keeps it that way on purpose. It ships NTAG21x under a single data sheet with three memory-capacity variants, and the branding stability across three generations (NT2H13/15/16) is deliberate. Converters, reader OEMs, and procurement teams treat NTAG21x as a single SKU family with a size parameter, and NXP's road-map holds the command set unchanged even as silicon processes migrate. The COT (chip-on-tape) wafer business is served by NXP's distribution network (Avnet, Arrow, Rutronik) with lead times typically 8-12 weeks and MOQ 100k wafers for direct allocations; smaller orders flow through NXP-authorised converters such as Smartrac (now Avery Dennison Smartrac), Linxens, Identiv, and Zebra.

• NTAG213 — 180 bytes total memory, 144 bytes user NDEF, 13.56 MHz ISO/IEC 14443-3 Type A, part number NT2H1311. The entry-level chip of the family. Used in ~80% of promotional NFC deployments because its per-unit cost (wafer / COT) is the lowest of any ISO-compliant NFC chip shipping in inlay volume.
• NTAG215 — 540 bytes total, 504 bytes user NDEF, part number NT2H1511. The memory-balance chip. Amiibo, vCards with photos, longer encrypted payloads, and applications that pre-load a few hundred bytes of metadata alongside the URL.
• NTAG216 — 924 bytes total, 888 bytes user NDEF, part number NT2H1611. The maximum-memory chip. Digital business cards with embedded contact photos, multi-language NDEF payloads, longer signed URLs, and developer test tags where headroom matters more than cost.
• All three chips are electrically identical. The ATQA, SAK, command set, page-based access model, and originality-signature algorithm are all the same. Only the total memory, the page address of the configuration block, and the GET_VERSION response byte differ.
• Drop-in compatible with NTAG21x-compatible host firmware. A reader that can program NTAG213 can program NTAG215 and NTAG216 without code changes if the firmware reads the GET_VERSION response and adjusts the upper-bound page address accordingly.
• Counterfeit chips marked 'NTAG213 compatible' usually run MIFARE Ultralight C or an unspecified Chinese-OEM Type-2 silicon. They typically lack the ASCII mirror feature, respond with a different GET_VERSION byte, and cannot produce a valid ECDSA originality signature. Your incoming-inspection test should GET_VERSION, then READ_SIG, then verify the signature against NXP's published public key.
• Inlay form factors: NTAG21x silicon ships in wet inlays (adhesive-backed antenna + chip, typical antenna sizes 22×22 mm, 35×35 mm, 40×25 mm, 85×54 mm CR80), dry inlays (for downstream lamination), and pre-laminated PVC cards. Converter-specific antenna tuning targets 13.56 MHz nominal resonance with Q factors of 20-40 depending on the end product (sticker vs. card vs. wristband).
• Variant cost ladder: at 100k-unit volume, indicative 2026 per-inlay prices run approximately USD 0.06-0.09 for NTAG213 wet inlays, USD 0.14-0.18 for NTAG215, and USD 0.24-0.32 for NTAG216. Printed and finished NTAG213 stickers typically retail at USD 0.20-0.35 each at 10k volume; these prices drop 20-40 % at 100k+ and another 10-15 % at 1M+.

Memory map — page-by-page reference

NTAG21x memory is a flat 4-byte-page address space with a fixed layout: a handful of factory pages (UID, lock bytes, CC), a user NDEF region, and a configuration block at the top of memory. Every reader firmware (Android NFC APIs, iOS Core NFC, Proxmark3 scripts, embedded ACR122U drivers) reasons in page addresses (0x00, 0x04, 0x28, etc.) rather than byte offsets, because the WRITE and READ commands address pages, not bytes. The map below is exhaustive for NTAG213 and shows the NTAG215/216 offsets where they differ.

• Memory is organized in 4-byte pages. NTAG213 has pages 0–44 (180 bytes), NTAG215 has pages 0–134 (540 bytes), NTAG216 has pages 0–230 (924 bytes). Page size is identical across the family.
• Pages 0–1 — UID (serial number). 7 bytes + 1 byte BCC (block check character). Read-only, factory-programmed, globally unique.
• Page 2 — internal use (byte 0) + static lock bytes (bytes 2–3). The lock bytes control per-page write-protection on pages 3–15; set a bit to permanently lock the corresponding page. Once locked, pages cannot be unlocked.
• Page 3 — Capability Container (CC). 4 bytes. Byte 0 = magic number (0xE1), byte 1 = version (0x10 for NTAG21x), byte 2 = total NDEF memory size / 8, byte 3 = read/write access byte. The CC is written once at personalization and typically locked.
• Pages 4 to (E)TLV-end. NDEF TLV data. NDEF messages are wrapped in a TLV frame: [0x03][length][NDEF bytes][0xFE terminator]. For NTAG213 the NDEF area ends at page 39 (page 40 onwards is configuration). For NTAG215 it ends at page 129. For NTAG216 at page 225.
• Dynamic lock bytes: NTAG213 at page 40, NTAG215 at page 130, NTAG216 at page 226. Provide per-block write-protection for pages above 15. Three bytes of dynamic lock bits plus one reserved byte.
• CFG0 and CFG1 pages — NTAG213 at pages 41–42, NTAG215 at 131–132, NTAG216 at 227–228. CFG0 byte 0 = MIRROR (UID/counter/PWD-AUTH ASCII mirror settings), byte 1 = reserved, byte 2 = MIRROR_PAGE (page where the mirror gets written), byte 3 = AUTH0 (page from which password authentication is required). CFG1 byte 0 = ACCESS (read/write-password protection and counter enable), bytes 1–3 = reserved.
• PWD page: NTAG213 at page 43, NTAG215 at 133, NTAG216 at 229. 4 bytes. Holds the 32-bit password for PWD_AUTH. Write-only after personalization; reads return 00000000.
• PACK page: NTAG213 at page 44, NTAG215 at 134, NTAG216 at 230. 2 bytes (first two bytes of the page). The Password Acknowledge value. Returned by the tag after a successful PWD_AUTH so the reader can confirm the tag is genuine.
• Page addressing quirks: WRITE (0xA2) always writes a full 4-byte page; partial-byte updates require a READ-modify-WRITE cycle at the reader. READ (0x30) returns 16 bytes (4 pages) starting at the requested address even when the caller only needs one page, so READ of page 4 returns pages 4, 5, 6, 7 in a single T=CL frame. FAST_READ (0x3A) batches up to 252 bytes in one APDU, which is the preferred command for bulk NDEF reads.
• Factory-default content: NTAG21x ships from NXP with pages 0-2 personalised (UID, BCC, lock bytes at all-zero) and pages 3 onwards in a default Type-2 CC pattern (0xE1, 0x10, size, 0x00). Many converters pre-programme CC and an empty NDEF TLV (0x03 0x00 0xFE ...) at wafer-sort to make downstream encoding faster; confirm with your converter whether inlays arrive CC-written or CC-blank.

Command set — 13 commands with hex opcodes

The NTAG21x command set fits on an index card — and unlike most things that fit on an index card, the brevity is the product of careful design rather than missing pages. That minimalism is deliberate: Type-2 tags are meant to be driven by any reader that implements the NFC Forum Type-2 Tag Operation spec. The commands below are listed in the order a typical tap exchanges them. Anti-collision first, then capability discovery (GET_VERSION), then reads, writes and optional authentication. Every command takes a single-byte opcode followed by its parameters, and responses are either a data payload or a 4-bit NAK/ACK. Frame timings are governed by the underlying ISO 14443-3 FDT (Frame Delay Time) of 1172/fc (≈86 µs) minimum.

• REQA (0x26) / WUPA (0x52). ISO 14443-3 entry commands. Put the tag into READY state; anti-collision follows.
• ANTICOLLISION / SELECT (0x93 / 0x95). Standard ISO 14443-3 Type A anti-collision. Returns the 7-byte UID in two cascade levels.
• HLTA (0x50 00): halt command. Tag enters HALT state until next RF field rise.
• GET_VERSION (0x60): returns 8 bytes identifying the chip per the NXP NTAG213_215_216 product short data sheet. Byte 1 = 0x04 (vendor ID, NXP Semiconductors). Byte 2 = 0x04 (product type, NTAG). Byte 3 = product subtype (0x02 for 50 pF tuning). Byte 4 / Byte 5 = major / minor version. Byte 6 is the storage size indicator: 0x0F = NTAG213 (144 bytes user), 0x11 = NTAG215 (504 bytes user), 0x13 = NTAG216 (888 bytes user). Byte 7 = 0x03 (protocol type, ISO/IEC 14443-3 compliant).
• READ (0x30 addr): reads 16 bytes starting at page addr (i.e. pages addr, addr+1, addr+2, addr+3). The most common read command. For higher throughput use FAST_READ.
• FAST_READ (0x3A start end). Reads a contiguous range of pages with a single APDU. Returns (end - start + 1) × 4 bytes. Up to 255 pages per command.
• WRITE (0xA2 addr data). Writes 4 bytes to the single page at addr. If the page is locked or above AUTH0 without prior PWD_AUTH, the tag returns a NAK.
• COMPATIBILITY_WRITE (0xA0 addr) + 16-byte data. Legacy Type-1 emulation. Only the first 4 bytes of the 16 are actually written. Kept for backwards compatibility with older NFC Forum T2T readers.
• READ_CNT (0x39 00): returns the 24-bit NFC counter. Incremented by the chip on every successful READ or FAST_READ when CFG1.ACCESS.NFC_CNT_EN is set.
• PWD_AUTH (0x1B pwd): password authentication. Send the 32-bit password; tag returns the 16-bit PACK on success, NAK on failure. Required to access pages ≥ AUTH0 when CFG1.ACCESS.PROT is set.
• READ_SIG (0x3C 00): returns the 32-byte ECDSA originality signature over the UID, signed by NXP's production key. Verify against NXP's published public key to prove the chip is authentic NXP silicon.
• NRG (internal): the tag's RNG is not directly command-accessible; it is used for the counter increment and password lock-out back-off.
• Error returns: malformed command returns 0x0 (NAK) or nothing. After 4 consecutive failed PWD_AUTH attempts the tag enters password lock-out and ignores all further PWD_AUTH commands until the RF field is dropped.
• ATQA / SAK: anti-collision response is ATQA = 0x0044 (7-byte UID, ISO 14443-3 Type A) and SAK = 0x00 (non-ISO 14443-4, Type-2). Readers use these values to branch to the Type-2 command set rather than the DESFire/ISO-4 command set; misconfigured readers that assume ISO 14443-4 on any 7-byte UID will fail on NTAG21x.
• T=CL frame sizing. The PICC to PCD response for FAST_READ is bounded by FSC (Frame Size for the Card) = 64 bytes default. To read an entire 924-byte NTAG216 a reader either raises FSC via an RATS (not usually supported at Type-2) or chunks the FAST_READ into 10-20 page batches. ACR1252U and OMNIKEY 5022 handle this chunking automatically; embedded drivers often need explicit batching logic.

NDEF TLV framing — the payload format every Type-2 reader assumes

NDEF is the universal NFC data format; every smartphone and every NFC reader knows how to parse it. An NDEF message on NTAG21x lives inside a simple TLV (Type-Length-Value) wrapper that Type-2 readers scan starting at page 4 — they expect a 0x03 type byte, a length byte, the NDEF bytes, then a 0xFE terminator. The message itself is one or more NDEF records, each with its own header (MB/ME/CF/SR/IL/TNF flags) plus type/payload. Mastering this framing is the difference between a tag that Android and iOS auto-launch and a tag that looks like random bytes to the host OS.

• An NDEF message on NTAG21x is wrapped in a TLV frame starting at page 4. Byte 0 = 0x03 (NDEF TLV tag), byte 1 = NDEF message length in bytes (or 0xFF followed by 2-byte length for messages > 254 bytes), bytes 2..n = NDEF message, byte n+1 = 0xFE (terminator TLV).
• NDEF message format: header byte (MB, ME, CF, SR, IL, TNF) + type length + payload length + optional ID length + type + optional ID + payload. For a URL record: TNF = 0x01 (Well Known), type = 'U', payload = [URL-prefix-byte][URL-string].
• URL prefix bytes: defined by NFC Forum RTD-URI 1.0. 0x00 = none, 0x01 = http://www., 0x02 = https://www., 0x03 = http://, 0x04 = https://, 0x05 = tel:, 0x06 = mailto:. Using prefix 0x04 + 'brand.com/v' saves 8 bytes vs. storing the full 'https://' inline.
• Text records: TNF = 0x01, type = 'T', payload = [status-byte][IANA-language-code][UTF-8-text]. Status byte bit 7 = UTF-16 flag, bits 5–0 = language code length.
• Multi-record messages: chain records with MB (Message Begin) on the first and ME (Message End) on the last; intermediates have both flags cleared. Typical pattern: URL record first (for OS URL launch) + optional Text record with human-readable label.
• Maximum NDEF sizes: NTAG213 = 137 bytes net (144 user − 7 TLV overhead), NTAG215 = 492 bytes net, NTAG216 = 872 bytes net. Subtract further if locking AUTH0-protected ranges or using ASCII mirror.
• External Type URIs: TNF = 0x04 (External Type) carries a reverse-DNS type (e.g. 'proudtek.com:badge') and an arbitrary payload. Used for proprietary app-launch tags; Android AAR (Application Auto-Run) records use this TNF with type 'android.com:pkg' to auto-launch a specific app when the tag is tapped on a device where the app is installed.
• iOS vs Android launch behaviour. iOS Core NFC auto-reads NDEF records on a system-level scan; URL records launch Safari for https:// URIs, other records appear in the Wallet/Notifications bubble. Android launches the default Browser or any app registered for the URI scheme. Review-card vendors always use https:// URLs (prefix 0x04) to maximise iOS launch reliability; proprietary URI schemes will prompt the user on iOS 15+ and fail on locked iPhones.

ASCII mirror — dynamic URL rewrites without re-programming

ASCII mirror is the single feature that distinguishes NTAG21x from vanilla Type-2 silicon and enables per-tap URL uniqueness without cryptography. The chip maintains an internal 24-bit counter (incremented on every READ or FAST_READ) and can splice the counter plus UID into a pre-reserved area of the NDEF URL, rendered as ASCII hex. Backends use this pattern to build tap-count analytics, anti-skim alerts (if the same counter value is observed twice, something is wrong), and personalised landing pages. All from a single encoded payload that never needs to be rewritten once the tag is in the field.

• ASCII mirror is the NTAG21x feature that lets the chip rewrite parts of its own NDEF payload on every READ, without any server round trip. It's the same mechanism that turns an otherwise-static NDEF URL into 'https://brand.com/v?uid=04A2B1C2D1E100&ctr=00012F'.
• Configure via the CFG0 MIRROR byte. Bits 7–6 = mirror mode: 00 = no mirror, 01 = UID mirror (14 ASCII hex chars), 10 = NFC counter mirror (6 ASCII hex chars), 11 = UID + counter mirror (20 ASCII chars). Bits 5–4 = mirror byte position within MIRROR_PAGE.
• The target position is CFG0.MIRROR_PAGE × 4 + CFG0.MIRROR_BYTE. The reader must ensure the NDEF URL template has 14 (or 6, or 20) ASCII 'X' placeholder characters starting at exactly that byte.
• Counter increment: the 24-bit NFC counter increments before the mirror is computed, so the first legitimate read after power-up always returns counter = 000001. This means the counter in a fresh scan is different from what was read during personalization. Production verification should skip the first N reads after power-on.
• PWD-AUTH mirror: mode 11 with AUTH_EN set also includes the PACK in the mirror, giving the backend a way to verify the tag responded correctly to the password challenge. This is the closest Type-2 gets to NTAG424 DNA's SUN without the full AES crypto.
• Mirror is writeable but not retroactively re-configurable. Once MIRROR is set to a non-default value in CFG0 it cannot be unset unless CFG0 itself was left unlocked. Production-encoded tags typically lock CFG0.
• Analytics-backend integration pattern. A typical review-card or loyalty setup queries the URL's uid + ctr parameters on every tap, rate-limits on the (uid, ctr) tuple to deduplicate near-simultaneous double reads, and stores the tuple in an append-only event table. BI tools plot counter delta over time per UID to show 'taps per day per location'. Counter-reset anomalies (ctr decreases, or jumps > 1000 in a single day) flag as potential clones.
• Mirror byte layout: the URL template embeds exactly 14 ASCII hex chars for UID mirror at CFG0.MIRROR_PAGE × 4 + CFG0.MIRROR_BYTE, followed by any separator plus exactly 6 hex chars for counter. Convention is placeholder character 'X', but any placeholder works as long as the reserved range is that exact length. Off-by-one errors in placeholder counting are the single most common personalisation bug.

Password protection and originality signature

It helps to picture NTAG21x security as a good lock on a screen door: it reliably turns away the casual and the opportunistic, and it will not detain a determined professional with time and the right equipment. NTAG21x provides two independent security primitives that together let integrators lock a tag against casual rewriting and prove that the silicon is authentic NXP. Password protection (PWD + PACK + AUTH0) is a 32-bit symmetric secret that gates reads or writes above a configurable page; originality signature (READ_SIG) is an ECDSA-P224 signature over the UID, pre-stored by NXP at wafer test. Neither primitive is a replacement for the full cryptographic tag authentication that NTAG424 DNA offers. PWD is brute-forceable in hours if the lock-out is not enabled, and the originality signature only proves silicon provenance, not payload authenticity. But together they raise the bar enough for most loyalty, promotional and event deployments.

• PWD and PACK — 32-bit password + 16-bit Password Acknowledge. Write to the PWD and PACK pages during personalization, then set CFG1.ACCESS.PROT and AUTH0 to the page from which protection starts. Any reader attempting to read/write pages ≥ AUTH0 must first PWD_AUTH.
• Lock-out: after a configurable number of failed authentications the tag enters permanent lock-out (CFG1.ACCESS.AUTHLIM). Default: no limit. Set to 1–7 for destructive lock-out on brute-force attempts.
• Originality signature (READ_SIG): a 32-byte ECDSA signature over the UID, precomputed by NXP during manufacturing and stored in a dedicated read-only region. The signature is produced with NXP's production ECDSA-P224 (NIST curve P-224) private key. The corresponding public key is published by NXP (AN11350, AN13452) so any reader can verify the signature and confirm the chip is authentic NXP silicon.
• Signature verification workflow — 1) READ_SIG to obtain the 32 bytes, 2) ANTICOLLISION to obtain the 7-byte UID, 3) ECDSA-verify signature against UID using NXP's public key. Incoming-inspection scripts typically check GET_VERSION byte 3 = 0x04 (NXP silicon) plus a valid signature to reject counterfeits.
• Lock-byte caveat: pages 2 and 3 (UID and CC) can never be locked dynamically; static lock bytes in page 2 only protect pages 3–15. Once the CC at page 3 is written, locking the 'lCC' bit in page 2 makes the CC read-only, which is the production default.
• Password diversification: never ship a fleet with the same PWD. Derive a per-tag PWD = truncate(HMAC-SHA256(master_key, UID), 4 bytes) and PACK = truncate(HMAC-SHA256(master_key || 0x01, UID), 2 bytes). The master_key stays in the encoding HSM; readers that need to unlock a specific tag first query its UID, then compute PWD on-the-fly. This keeps a single compromised tag from revealing the master secret and makes fleet lock-down trivial to audit.
• Originality-signature verification code. The ECDSA-P224 curve is NIST P-224 (secp224r1). NXP publishes both the public key and test vectors in AN11350. Reader code typically calls a standard TLS library (BoringSSL, mbedTLS, OpenSSL) with the secp224r1 curve preselected; verification takes under 5 ms on modern ARM Cortex-A processors and under 50 ms on ESP32-class MCUs. Failure modes to handle: corrupted SIG bytes (retry READ_SIG once), tag returns all-zero SIG (counterfeit or un-personalised), signature valid but UID does not match reader's anti-collision result (mismatched chip).
• Lock-out semantics: CFG1.ACCESS.AUTHLIM can be set to 1-7 (0 = unlimited). After AUTHLIM consecutive failed PWD_AUTH the tag permanently ignores further PWD_AUTH attempts until the RF field drops. For event wristbands, AUTHLIM = 3 with destructive lock-out turns a lost or stolen tag into a brick if the attendee's security code is wrong three times.

Commercial deployments and application fit

NTAG21x silicon ships in billions of units every year because it hits a sweet spot between price, memory, features and tooling. The chip family is specified by default in virtually every consumer NFC deployment where cryptography is not required: tap-to-review cards, promotional tap campaigns, event wristbands, vCard business cards, consumer-IoT pairing labels. Each of those verticals has a preferred variant (213, 215, or 216) dictated by payload size and cost target; the decision tree almost always reduces to 'how many bytes of NDEF does the application need, and what's the BOM target?'

• Google Review NFC cards, hotel guest touchpoints, restaurant tabletop prompts. NTAG213 is the default choice. 144 bytes of user memory is enough for a 100-character review URL with UTM parameters and NFC counter mirroring; per-unit cost at volume is under a dime.
• NFC business cards: NTAG215 is the sweet spot. 504 bytes of NDEF comfortably holds a full vCard (name, title, multi-line address, phone, email, website) plus a PNG avatar under 250 bytes. NTAG216 is preferred when the card carries a photo or a long bio.
• Event and festival wristbands. NTAG213 for single-use paper/Tyvek wristbands, NTAG215 for reusable silicone wristbands where the operator wants to store a local credential (member number, ticket tier) alongside the URL.
• Brand authentication at low-to-medium risk. NTAG213 with ASCII mirror + NFC counter gives a decent 'tap count anomaly detection' layer. For high-counterfeit-risk goods (luxury, pharmaceuticals) upgrade to NTAG424 DNA for true cryptographic authentication.
• Consumer IoT pairing (Bluetooth speakers, smart plugs). NTAG215 is common. Enough memory for a pairing-record NDEF (Bluetooth handover) plus a backup URL for setup instructions.
• Amiibo and toys-to-life. NTAG215 specifically, 540 bytes is the Nintendo spec. Do not specify NTAG213 or NTAG216 for amiibo-compatible deployments; the game software bit-checks memory size.
• Healthcare and medical device links. NTAG215 with PWD-AUTH for controlled-access metadata. Low enough cost for disposables; enough memory for device serial, recall flags and calibration dates.
• Social-media and creator-economy tap tags. NTAG213 in silicone rings, NTAG215 in metal cards. Linktree, Popl, Mobilo, V1CE, and similar personal-profile NFC services drive the upper end of the consumer tag market; average ASP USD 8-40 per finished unit reflects the premium packaging rather than the underlying NTAG213 silicon.
• Where NTAG21x is wrong. Multi-application enterprise access control (use MIFARE DESFire EV3), cryptographic brand authentication (use NTAG424 DNA), UHF item-level retail (use UCODE 8/9 or Monza R6).

NXP reference documents and datasheets

NXP publishes NTAG21x documentation publicly (no NDA), which is a deliberate choice given the chip's role as a commodity NFC interface. The documents listed here cover the chip itself, the originality-signature validation flow, the feature comparison with higher-end NTAG siblings, and the underlying NFC Forum and ISO 14443 standards. Reader-firmware developers reference these documents routinely; integrators designing a new NTAG21x product should read at least the product short data sheet and AN11350 before writing personalisation scripts.

• NTAG213 / 215 / 216 Product Short Data Sheet (NXP document 279532, latest rev). The canonical reference for pin-out, electrical characteristics, memory organization and command set.
• AN11350 — NTAG21x Originality Signature Validation. Contains the ECDSA-P224 public key in hex, pseudocode for verification, and test vectors.
• AN13452 — NTAG family command and feature comparison (NTAG213/215/216 vs. NTAG413 vs. NTAG424 DNA). Invaluable when migrating a design from NTAG21x up to the DNA family.
• AN11322 — NTAG21x originality check implementation guide for Android / iOS host apps.
• NFC Forum Type-2 Tag Operation Specification v1.2 — the vendor-neutral spec for the command set and TLV framing. NTAG21x is a proper superset.
• ISO/IEC 14443-3:2018 — anti-collision and transmission protocol layer. Together with NFC Forum T2T defines everything the reader firmware must implement.
• NFC Forum RTD-URI 1.0 — the well-known URI record type definition that specifies the prefix-byte table (0x00-0x23) and the URL encoding rules; used in every well-formed NDEF URL record.
• NXP TagWriter and TagXplorer. NXP's reference desktop/mobile encoding utilities. Both speak the NTAG21x command set natively and are useful sanity tools during early development before in-house encoding software is ready.

Programming workflow — encode, verify, lock

Production encoding of NTAG21x converts a blank or CC-only inlay into a final, tamper-resistant product tag. The workflow below is the same pattern Proud Tek and most high-volume converters follow, whether the end product is a review card, a wristband, or a business card. Each step has a failure mode and a specific recovery. Treating the workflow as a reliable assembly-line process rather than a manual operation is what delivers the sub-0.5 % field-defect rates that the review-card and event markets now expect.

1. Step 1
   Step 1 — Anti-collision plus GET_VERSION. Confirm the inlay under the reader returns ATQA = 0x0044, SAK = 0x00, and GET_VERSION byte 1 = 0x04 (NXP vendor ID) and byte 2 = 0x04 (NTAG product type) plus byte 6 matching the expected variant (0x0F for 213, 0x11 for 215, 0x13 for 216). Reject inlays that fail any check. They are either counterfeit or damaged.
2. Step 2
   Step 2 — READ_SIG plus offline ECDSA-P224 verification. Read the 32-byte originality signature, verify against NXP's published public key (AN11350), and log {UID, SIG, timestamp, operator, batch number} in an append-only database. Rejecting the ~0.01 % of inlays that fail signature verification is what separates a mature line from a hobbyist setup.
3. Step 3
   Step 3 — Build NDEF TLV. Compose the NDEF message (typically a URL record with RTD-URI prefix 0x04 for https://), pad the URL to include placeholder 'X' characters at the exact byte offset where ASCII mirror will splice UID and counter values. Wrap in TLV: 0x03 | length | NDEF bytes | 0xFE. Pad the remaining user-memory pages with 0x00 so that FAST_READ returns a deterministic pattern.
4. Step 4
   Step 4 — Write CC plus NDEF using FAST_WRITE-equivalent chunking. Issue WRITE (0xA2) commands page by page starting at page 3 (CC: 0xE1 0x10 size 0x00), then page 4 onwards with the NDEF TLV. Some reader drivers batch into multi-page COMPATIBILITY_WRITE but NTAG21x officially requires single-page WRITE. Verify by FAST_READ of the just-written range and byte-compare.
5. Step 5
   Step 5 — Configure ASCII mirror and PWD-AUTH (optional). Write CFG0 with MIRROR bits (11 for UID+counter), MIRROR_PAGE and MIRROR_BYTE pointing at the placeholder location, and AUTH0 set to the page from which password protection starts. Write CFG1 with ACCESS bits (protect writes only, enable counter). Write PWD and PACK. The order matters: always write MIRROR before AUTH0, and PWD before setting ACCESS.PROT.
6. Step 6
   Step 6 — Seal with lock bytes. Write static lock bytes in page 2 (protect pages 3-15) and dynamic lock bytes (page 40 / 130 / 226) to permanently seal all user NDEF pages. The tag is now read-only to any reader that does not know the PWD. Verify one last time with FAST_READ; attempt a sentinel WRITE to a locked page and confirm NAK.
7. Step 7
   Step 7 — Functional verification with a smartphone. Tap the finished tag with an Android phone (Core NFC or Android NFC API) and confirm the URL launches. Tap with an iPhone (iOS Core NFC auto-scan) and confirm the URL launches Safari. These two tests catch 99 % of personalisation errors: missing TLS prefix byte, unwritten terminator, misaligned mirror placeholder.
8. Step 8
   Step 8 — Batch audit. Sample 1-3 % of every production lot for deep verification: FAST_READ the full memory, decode the NDEF, verify URL against the batch manifest, verify counter resets and mirror renders correctly after 100 simulated taps. File the audit logs in a signed, append-only archive for the product's shelf-life (typically 2-5 years for promotional tags, 10+ years for long-lived identity tags). ISO 27001 Annex A.12.4 (logging) applies for credential-grade deployments.

Specifications at a glance

The specifications table below lets procurement, design and engineering teams confirm the NTAG21x variant choice in a single glance. The key decision parameter is the user NDEF memory: anything under ~120 bytes fits NTAG213, 120-480 bytes fits NTAG215, and 480-870 bytes fits NTAG216. GET_VERSION byte 6 is the deterministic signal readers should use to auto-detect variant rather than guessing from UID or ATQA.

FAQ