NFC Tag Capacity Calculator

NFC Tag Memory Capacity Guide

Choosing the right NFC tag depends on the data you need to store. NDEF messages can vary from a few bytes (a URL) to several kilobytes (a vCard with photo). Understanding tag memory helps you select the appropriate tag type and plan your NDEF data layout.

Tag Memory Breakdown

NFC tag memory is not entirely available for user data. A portion is reserved for the tag's UID, configuration pages, lock bytes, and capability container (CC). For example, a MIFARE Ultralight NTAG213 has 144 bytes total, with about 130 bytes usable for NDEF data. The NTAG215 has 504 bytes (useful for Amiibo), and the NTAG216 has 888 bytes for larger payloads. Type 4 tags (like MIFARE DESFire) can store up to several KB and support file systems.

NDEF Data Sizing

NDEF records have overhead: each record has a 3+ byte header (TNF, type length, payload length, optional ID and type fields). A URI record with a short URL (e.g., https://cupass.com) needs about 20-30 bytes. A vCard (contact info) may need 200-500 bytes depending on fields. A Smart Poster with URI and title text needs 100-200 bytes. WiFi configuration records need 100-150 bytes. Bluetooth pairing records need 80-120 bytes. Use our NDEF Parser to check the byte size of your NDEF message before selecting a tag.

Memory Layout of NTAG Series Tags

NXP NTAG tags share a consistent page-based memory architecture where each page is 4 bytes. The NTAG213 has 45 pages (180 bytes total): pages 0-1 hold the 7-byte UID plus BCC, page 2 stores internal/lock bytes, page 3 is the Capability Container (CC) with 4 bytes encoding version, memory size, and read-write grants, and pages 4-39 are user data (144 bytes usable). The NTAG215 extends to 135 pages (540 bytes, 504 usable) — famously used by Nintendo Amiibo figures which store character data, game progress, and costume modifications. The NTAG216 reaches 231 pages (924 bytes, 888 usable), suitable for vCard records with photo thumbnails or multi-record Smart Poster messages. Dynamic lock bytes on pages 0x28-0x2A (NTAG213) or equivalent positions on larger tags allow per-page or per-block write protection after initial programming.

Capability Container (CC) Structure

The CC is a 4-byte or 7-byte structure at a fixed location in Type 2 tags (page 3, offset 12). Byte 0 is the magic number 0xE1 indicating an NFC Forum tag. Byte 1 encodes the version and memory size: the upper nibble is the major version (0x1 for NFC Forum Type 2), and the lower nibble multiplied by 8 gives the tag size in bytes — so 0x11 means 8 bytes (too small, likely a defect), 0x10 means 0 (dynamic, read from config), and 0x12 means 16 bytes. Byte 2 encodes read/write access permissions: 0x00 means full read-write access, while 0xFF means read-only after being locked. Byte 3 is the message type and size for the NDEF TLV, or 0x00 for no pre-configured message. Understanding the CC is critical when manufacturing custom NFC tags or debugging why a tag refuses writes — a locked CC byte 2 value (0xFF) permanently prevents modification.

NDEF TLV and Lock Mechanism

The NDEF message on a Type 2 tag is wrapped in a Type-Length-Value (TLV) structure starting with T=0x03 (NDEF message TLV type). The L field uses 1-3 bytes depending on message size: for messages under 255 bytes, L is a single byte; for 255-65535 bytes, L is 0xFF followed by two bytes in big-endian order. After the NDEF TLV, a proprietary TLV (T=0xFE) or empty TLV (T=0x00) may pad remaining space. Lock control TLVs (T=0x02) define which pages are permanently locked. Static lock bytes on page 2 cover pages 3-15, while dynamic lock bytes (if present) extend locking to additional pages. When calculating usable capacity, this tool automatically subtracts CC bytes (4 bytes), static lock bytes (varies by tag), and dynamic lock bytes from the total memory, giving you the realistic NDEF payload space.

Type 4 Tag File System vs Type 2 Linear Model

Type 2 tags (NTAG, Ultralight) use a linear memory model: user data starts at a fixed page and extends contiguously, making them simple to program but limited in flexibility. Type 4 tags (DESFire, ISO 14443-4) implement a file system with application definitions (ADF), elementary files (EF), and access control lists. An EF of type NDEF (file identifier 0x0001 or 0x0003 for EF2) contains the NDEF message, with a 2-byte length prefix. The file system overhead reduces usable space but enables multiple applications on a single tag, mutual authentication, and encrypted communication. MIFARE DESFire EV2/EV3 with 4KB or 8KB can hold multiple NDEF files alongside transit passes and access control credentials, making them ideal for multi-application deployments. However, the complexity of Type 4 file management means writing NDEF requires SELECT by DF name, SELECT by AID, CREATE or READ operations via ISO 7816-4 command set.

Amiibo and Gaming Applications

Nintendo Amiibo figures use NTAG215 tags (504 bytes usable), storing a 532-byte data structure that includes character model data, game save progress, and a per-figure unique identifier. The Amiibo data format reserves the first 36 bytes for game-specific metadata, followed by 468 bytes of modifiable data (such as leveled-up stats and unlocked costumes), with a 28-byte cryptographic signature using AES-128. Despite the NTAG215 having only 504 usable NDEF bytes, the Amiibo system uses raw page reads bypassing NDEF entirely. This is a key consideration for hobbyists creating custom Amiibo cards: you need an NFC reader supporting raw ISO 14443-3 commands, not just NDEF-level operations. Tools like the TagMo app on Android can read and write Amiibo binary data directly to blank NTAG215 tags.

Tag Selection Strategy for Real-World Projects

For URL-based smart posters and business cards, NTAG213 (144 bytes) is sufficient and the most cost-effective option at roughly $0.10-0.15 per tag in bulk. For vCard with a profile photo or multi-record messages, NTAG216 (888 bytes) provides comfortable headroom. Event ticketing and single-use applications favor MIFARE Ultralight (46 bytes usable) due to extreme low cost. Transit and payment systems require Type 4 tags with DESFire EV2/EV3 for cryptographic security and multi-application support. Inventory and asset tracking benefit from ISO 15693 Type 5 tags (ICODE SLIX) with longer read range (up to 1.5 meters) and larger memory. Always prototype with actual tag hardware before committing to a production order — manufacturer variations in antenna tuning and EEPROM quality can affect read reliability in real-world enclosures and environments.