RFID Tag Encoding and Data Structures

An RFID tag's usefulness comes down to what data is written into its memory and how that data is structured. Understanding the memory banks on a typical passive UHF tag and the standard encoding schemes used to fill them helps operations teams avoid the interoperability problems that arise from ad hoc, non-standard encoding.

Memory Banks on a Passive UHF Tag

Most passive UHF tags following the widely used Gen2 air-interface protocol expose four logical memory banks:

  • Reserved memory — holds the kill and access passwords used to permanently disable or lock a tag
  • EPC memory — holds the Electronic Product Code, the primary identifier read during normal operation
  • TID memory — a factory-programmed, read-only tag identifier unique to the chip itself, distinct from the EPC
  • User memory — optional additional space, present on some chip models, available for application-specific data beyond the standard identifier

The distinction between EPC and TID matters operationally: the EPC is what the business process assigns and can typically be rewritten, while the TID is a permanent chip-level serial number useful for security and tag-authenticity checks.

Reserved EPC (rewritable) TID (fixed, factory) User Four logical memory banks of a Gen2 UHF tag
Standard EPC Encoding Schemes

Rather than each company inventing its own bit layout, the EPC standard defines encoding schemes that map real-world identifiers — GS1 GTINs, serial numbers, license plates, general identifiers — into a defined binary structure within the EPC memory bank. This standardization is what allows a reader from one vendor to correctly interpret a tag encoded by a completely different system, as long as both follow the same published scheme.

A properly encoded tag typically separates a header (identifying which encoding scheme is in use), a company or manufacturer prefix, an item or object class reference, and a serial number, so that any compliant reader can decode the full hierarchy without needing a lookup table specific to that one deployment.

Why Ad Hoc Encoding Causes Problems

Organizations that encode arbitrary internal codes into tag memory without following a standard scheme lose interoperability the moment a tag needs to be read by a partner, a third-party logistics provider, or a different reader vendor's software. It also complicates any future migration, since undocumented or inconsistent encoding practices are difficult to reverse-engineer once the people who set them up have moved on.

Locking and Security Considerations

Individual memory banks can be locked to prevent further writes, and access or kill passwords can restrict who can modify or permanently disable a tag. A common pattern locks the EPC after initial encoding to prevent accidental overwrite during normal handling, while leaving user memory open for updates such as a maintenance log or inspection date that legitimately needs to change over the item's life.

Practical Guidance

Before a large-scale tagging project begins, defining the encoding scheme, prefix structure, and locking policy up front avoids costly rework later. Reusing an existing standard scheme rather than inventing a proprietary one preserves the ability to work with future partners, software, and hardware without a custom translation layer.