What is the difference between EPC and TID?

EPC is normally commissioned by the application owner to identify the tagged object during inventory. TID identifies the tag IC allocation, designer/model and optional factory serialization; its standard identity region is manufacturer-written and permalocked.

Can User memory replace a writable TID?

Often, yes. If the requirement is simply to store a mutable on-tag value, User memory is the standards-aligned choice when the selected IC provides enough capacity and the reader workflow supports it.

Which bank is returned during normal inventory?

The EPC bank supplies the inventory-facing identifier in ordinary Gen2 workflows. Reading TID or User memory generally requires an additional memory operation.

Should personal or frequently changing data be stored on the tag?

Usually not. A controlled backend record is easier to update, audit and protect. Put only the minimum lookup identifier on the tag.

EPC vs TID vs User Memory in UHF RFID

Plain-language summary

EPC is the label your operation puts on the item. TID is the chip maker's model plate. User memory is a small optional note area. A database is the full file cabinet. Put the data where its ownership, size and change rate fit; do not modify the model plate just because the reader displays all four areas together.

The shortest useful comparison

Location	Selector	Assigned by	Main job	Inventory response?	Change expectation
Reserved	`00b`	Owner / IC defaults	Access and Kill passwords	No	IC- and state-dependent
EPC	`01b`	Application owner	Identify the tagged object	Yes	Commission, verify, then optionally lock
TID	`10b`	IC designer/manufacturer	Identify the responding IC type and optional serial	Not in the ordinary EPC field	Standard identity region is factory permalocked
User	`11b`	Application owner	Optional auxiliary on-tag data	No	Writable if implemented and permitted
Backend	Not on tag	System owner	History, relationships, permissions and large records	Looked up after reading a key	Controlled by database policy

EPC: the identifier designed for commissioning

EPC memory is the operational identity surface. GS1's Tag Data Standard defines encodings for GS1 keys, while the Gen2 protocol makes the EPC available in the inventory exchange. That is why EPC works well for fast population discovery: a reader can receive object identifiers without issuing a separate read for every tag.

EPC memory also contains protocol-control information around the EPC data. A raw memory dump therefore needs to be distinguished from the business identifier shown by middleware. Capacity and supported lock controls vary by chip; read the actual IC data sheet before fixing a data length.

GOOD FIT

Asset or item identifier

The code your warehouse, library, production line or inventory system expects to see first.

WATCH

Duplicate commissioning

EPC's usefulness depends on the issuing process. A writable field is not automatically unique.

TID: identity metadata about the IC

For an E2-class tag, GS1 assigns the first TID fields to allocation class, feature flags, MDID and TMN. When XTID serialization is present, the extended structure adds manufacturer-defined and serialized information. GS1 requires the standard identity region—and the complete XTID when present—to be permanently locked at manufacture.

TID can help middleware recognize an IC model, diagnose a tag population, or check whether an observed EPC/TID pair matches an enrolled record. It should not be used as a general notes field. Nor should “TID present” be confused with cryptographic authentication.

A useful diagnostic pattern

Read EPC for the object identity, then read TID on exception or commissioning. If the same EPC unexpectedly appears with several TIDs, or one TID appears with incompatible EPC history, flag the event for investigation. The backend supplies the policy; TID alone does not decide authenticity.

User memory: useful when data must travel with the item

User memory is optional. Some tags provide none; others provide a few words or much more. It can hold an internal status code, a compact maintenance value or application information that must remain available when the backend is unreachable.

There is a cost: a separate read takes air time, programming takes RF margin, and every on-tag copy creates another data-governance problem. If a value is private, frequently updated or needs an audit trail, a backend is usually a better home.

A decision tree based on the requirement—not the product label

01
Must the identifier be returned during normal inventory?
Use EPC. Design a controlled commissioning process and verify uniqueness in the relevant namespace.
02
Must a small value remain physically on the tag?
Evaluate User memory capacity, access control, write threshold and retention in the selected IC.
03
Is the data large, sensitive, relational or frequently changed?
Keep a lookup key on the tag and store the record in a controlled backend.
04
Does the test explicitly need the value to appear at MB10?
Only then evaluate a special changeable-TID tag, document that the value is user-controlled, and validate its reader-specific behavior.

Five requests that sound like “writable TID” but are not

“Give every item our serial”

Commission that serial or a standards-based identifier in EPC.

“Change status after service”

Use a compact User-memory flag or, preferably for auditability, update the backend.

“Detect tag replacement”

Enroll the expected EPC/TID relationship and investigate mismatches; do not make TID writable.

“Store the full product record”

Use a backend. A passive tag is not a document database.

“Prove the item is genuine”

Use a documented authentication architecture, potentially including a secure tag IC. A copied static identifier is not proof.

Where a changeable-TID tag is specifically not recommended

Routine EPC commissioning

Use the bank designed for the job. Special MB10 behavior adds no advantage.

Frequently updated workflow state

Repeated special-memory programming adds RF and endurance uncertainty. Keep state in a database.

Personal or confidential payload

Static tag memory can be read outside the intended application unless suitable controls exist. Minimize on-tag data.

Authentication based on factory identity

A user-controlled TID cannot serve as the immutable property the design assumes.

Large mixed-reader fleets

Undocumented behavior may vary across SDKs and firmware. Standard banks and documented ICs reduce integration risk.

Regulated records without qualification

Use a documented, validated architecture with traceability and change control.

Bottom line

If you want to name the object, write EPC. If you need a small note on the object, consider User memory. If you need a real record, use a database. Change MB10 only when your authorized test specifically needs MB10 behavior and you accept that the result is no longer a normal factory TID.

Next practical question: Why can a tag read successfully but fail to write at the same distance? ↗

Primary references

GS1: How data is stored on a RAIN RFID tag ↗ — roles of Reserved, EPC, TID and User memory.
GS1: EPC Tag Data Standard ↗ — normative EPC and TID data structures.
NXP: UCODE 9 data sheet ↗ — concrete example of EPC, TID and lock implementation.