Two chips that look identical can behave completely differently once you try to store data on them, because the memory layout, not the plastic, decides what fits and what a reader can do with it. This explainer separates the identifier a chip is born with from the memory you can write, sets out how much the common families hold, and explains where the different encoding models (NDEF, raw sectors, application files, UHF banks) apply. It closes with the part that matters commercially: which encoding to keep under your own control. To hand a batch to a supplier, see our RFID encoding service page.
Table of Contents
UID versus user memory
Almost every RFID and NFC chip carries a unique identifier, or UID, programmed at the factory and locked read-only. It is the serial number a reader sees during anti-collision, before any data exchange. The UID is useful for telling one tag from another, but it is not user memory and it is not, on its own, a security feature: many chips return the UID to any reader, and a “reads the UID” test proves only that the radio works, not that an application will function.
User memory is separate: the writable space where an application stores a URL, a record, keys or files. When you compare chips, compare user memory and its structure, not the UID length. Two questions follow: how much space there is, and how it is organised.
How much the common chips hold
Capacities differ by an order of magnitude across the families, which is exactly why chip choice is a data question first.
| Chip / family | Frequency | User memory | Structure |
|---|---|---|---|
| EM4305 | 125 kHz (LF) | 512-bit EEPROM (part reserved for configuration) | 32-bit words |
| T5577 | 125 kHz (LF) | Seven 32-bit user blocks in the main page | 32-bit blocks, plus config and read-only trace data |
| MIFARE Classic 1K | 13.56 MHz (HF) | About 752 usable bytes of 1,024 | 16 sectors of four 16-byte blocks |
| NTAG213 / 215 / 216 | 13.56 MHz (HF) | 144 / 504 / 888 bytes | 4-byte pages |
| MIFARE DESFire EV2/EV3 | 13.56 MHz (HF) | 2 KB / 4 KB / 8 KB variants | File system with applications |
| UHF EPC Gen2 | 860 to 960 MHz (UHF) | EPC plus optional User bank | Four memory banks |
A few notes keep this honest. The EM4305’s 512-bit EEPROM gives up several words to configuration, the device identifier and protection, so usable space is smaller than the headline. The T5577 is best described by structure, a handful of 32-bit user blocks plus configuration and read-only trace data, because how much is usable depends on how you configure it. On MIFARE Classic 1K, the 1,024 bytes include a sector trailer in every sector and a manufacturer block, which is why the usable figure is about 752 bytes. The NTAG figures are from the NXP data sheet, as shown on our NTAG213 labels page. Always confirm the exact figure against the data sheet for the specific part, because options and sub-variants move these numbers.
Three ways data is organised
The encoding model is as important as the size.
Page and sector memory (raw). LF chips and MIFARE Classic present a flat grid of blocks or pages addressed by number. A write replaces a whole block or page, with no built-in notion of “a record”. On MIFARE Classic the last block of each sector is a trailer holding two keys and the access bits; write the wrong value there and the sector can be locked permanently. Raw access gives maximum control and efficiency, at the cost of a reader that understands your private layout.
NDEF (the interoperable format). On NFC Forum tags such as NTAG, the NFC Data Exchange Format is the shared container that lets any compliant phone read the content without a custom app. The message sits inside a short TLV wrapper (a type byte 0x03, a length, the records, then a 0xFE terminator), and a URI record uses a one-byte prefix so a scheme like https:// costs a single byte. NDEF is what makes a tap open a link on a phone that has never seen the tag; the trade-off is a few bytes of framing overhead and a fixed set of record types. How that maps onto the chip’s pages is covered in the companion post, how NFC tags work with smartphones.
Application file systems. MIFARE DESFire and Java Card-based cards move up a level: you create applications, each with its own keys and files, rather than writing bare blocks. This suits a credential that must carry several independent data sets under separate keys, for example access and cashless functions that should not share a secret. The Java Card and JCOP explainer covers the programmable end of this spectrum.
The UHF EPC Gen2 memory model
UHF tags that follow the EPC Gen2 air interface (ISO/IEC 18000-63) divide memory into four banks, each with a distinct job:
- Bank 0, Reserved. Holds the kill password and the access password, both 32 bits. Left at zero in production, anyone can silence or unlock the tag, so set and record them deliberately.
- Bank 1, EPC. Carries the Electronic Product Code that readers inventory, typically 96 bits and extendable further. It begins with a CRC-16 the chip computes and a 16-bit Protocol Control (PC) word that declares the EPC length; setting that length wrong is a common cause of a tag that reads but appears corrupted, because readers trust the PC word, not the actual content.
- Bank 2, TID. A factory-programmed, read-only chip identifier. Because it cannot be altered, it is the better source of identity when you need to detect cloned tags.
- Bank 3, User. Optional writable space that ranges from zero on low-cost parts up to several hundred bits on others. Verify the data sheet before you design anything that depends on it.
For retail and logistics, the encoding scheme in Bank 1 (for example SGTIN for item-level tagging) usually needs a licensed GS1 company prefix and a serial that is never reused. The public GS1 EPC Tag Data Standard is the reference.
Which encoding to keep in-house
Not all encoding is equal, and the commercial risk sits in a few specific places.
- Anything involving secret keys. MIFARE Classic key rotation, DESFire application keys and UHF access and kill passwords define who can read, write or disable your tags. Keep their generation and diversification under your own control, or with a party you trust contractually; a shared default key across a batch is one lock for every door.
- Identity and serialisation. The mapping between a serial number and a record, and the file recording which serial went on which item, is your audit trail. Own it.
- Lock decisions. Static and dynamic lock bits, sector trailers and the UHF Lock command are one-way. Approve the encoded content and the future update process before any permanent lock is set.
By contrast, bulk NDEF encoding of a shared https URL, or serialised writes verified against a manifest, are routine to delegate, provided the tag is always read back and compared byte-for-byte before it ships. What should not leave your control is the key material and the identity mapping that make the tags trustworthy. Where you do delegate, agree the record format, verification step, output file and locking policy in writing first; our RFID encoding service page lists what to confirm, and you can send your requirement with the chip, payload and destination country to get a sample that matches the real job.
