RFID encoding is the step where a unique identity gets written into a tag’s memory, most often the EPC (Electronic Product Code). Done properly it is not a single action but three. First the data is written, then it is read back to confirm the write actually worked, and finally the memory is locked so nobody can overwrite it. Skipping the read back turns encoding into guesswork, because a write can fail silently and still look fine. On a modern production line all three steps happen in one pass at high speed, so every tag leaves the factory carrying the right identity, verified and secured.
A blank RFID tag is not much use. It can talk to a reader, but it has nothing meaningful to say until someone writes an identity into it. That writing step is encoding, and it is where a generic inlay becomes a specific product: this bottle, this garment, this pallet. Get it right and the tag carries a trustworthy identity for the rest of its life. Get it wrong, or fail to check it, and you have shipped a tag that points at nothing, or worse, at the wrong thing.
This article explains what RFID encoding is, what actually gets written, why verification and locking matter as much as the write itself, and how the whole thing runs at production speed.
What is RFID encoding?
RFID encoding is the process of writing data into the memory of an RFID tag. In the vast majority of cases that data is the EPC, a unique identifier that tells any reader exactly which item the tag belongs to. For RAIN RFID this follows the EPC Gen2 protocol, standardised as ISO/IEC 18000-63.
The word encoding sometimes gets used loosely to mean the whole personalisation step, but at its core it is simple. A reader sends a write command, the tag stores the value in the right part of its memory, and from then on it reports that value whenever it is read. The complexity is not in the writing itself, it is in making sure the writing was correct and cannot be undone.
What actually gets written: the EPC and the memory banks
A RAIN tag does not have one big block of memory. It has several banks, and understanding them makes encoding much clearer.
The EPC bank is the one encoding usually targets. It holds the identifier that gets serialised per item, often as a GS1 structure such as an SGTIN, so every single tag carries a unique value. Then there is the TID, a serial number programmed into the chip at the factory that is read only and cannot be changed, which is useful for authentication because it is fixed. There is also a user memory area on some chips for extra application data, and a reserved bank that holds the access and kill passwords used to protect and, if ever needed, retire the tag.
So EPC encoding is the everyday work, writing a unique identity into the EPC bank. The TID is already there and untouchable, and the other banks come into play when an application needs extra data or security.
The three steps of reliable encoding
Reliable encoding is really three actions, not one, and treating it as a single write is where a lot of quality problems begin.
Write
The write is the obvious part. The system sends the EPC value to the tag and the tag stores it. For a standard 96 bit EPC this takes on the order of twenty milliseconds, though it varies with the chip.
Verify with a read back
This is the step people skip and regret. After writing, the system reads the value straight back off the tag and compares it to what it meant to write. A write can fail without any obvious sign, especially at speed or on a marginal tag, and the only way to know it succeeded is to check. A write that is never verified is not encoding, it is hoping. Read back is what turns a hopeful write into a guaranteed one.
Lock
Once the right value is confirmed, locking protects it. A lock command secures the memory so it cannot be overwritten, either by accident later in the process or deliberately by someone downstream. Locking can be reversible with a password or made permanent, depending on the application. For retail it mostly guards against accidental corruption. For pharmaceutical goods, luxury items and anything where authenticity matters, it is a genuine security control.
Why verification is not negotiable
It is worth dwelling on the read back, because it is the difference between an encoding process you can trust and one you cannot.
Imagine a line writing hundreds of thousands of unique EPCs an hour. If even a small fraction of writes fail silently and nobody checks, that is a steady stream of tags going out with missing or wrong identities. In a serialised system, where every EPC is meant to be unique and tied to a specific item, that is not a cosmetic flaw. It breaks the link between the physical product and everything that depends on the tag downstream, from inventory systems to a customs check to a digital product passport.
Verification closes that gap. By reading back every tag and comparing it against the intended value, the system catches a bad write the instant it happens and can mark the tag for rejection before it goes any further. That is why encoding and verification belong together in the same step, not as an afterthought.
How fast can RFID encoding be?
Encoding is often assumed to be the slow part of production, and on older setups it could be. On modern equipment it is fast and, more importantly, predictable. The times below are per tag for a single test point, and they scale in a linear, foreseeable way, which lets integrators estimate real throughput in advance.
| Operation | Typical time |
| Go or no go test point | ~4 ms |
| Read EPC | ~5 ms |
| Write EPC (96 bit) | ~21 ms |
| Write EPC (96 bit) and lock | ~26 ms |
Times depend on chip type and configuration. The useful property is that they scale predictably, so achievable units per hour can be worked out before committing.
The takeaway is that writing and locking a full EPC lands in the region of twenty five milliseconds, and spread across multiple lanes that adds up to very high throughput without holding the line back.
Where encoding happens: standalone encoders and inline production
There are two broad places encoding gets done, and the right choice depends on volume.
For lower volumes, a standalone RFID encoding machine or an RFID label printer with a built in encoder does the job. You feed it tags, it writes and often prints them, and it suits short runs and on demand work.
For high volume production, encoding moves onto the line itself. Here an inline system tests, encodes and locks each tag as the web runs through at full speed, so encoding is no longer a separate stage but part of the same pass as quality testing. This is where the real efficiency lives, because the tag is verified, written and secured in one go rather than being handled three times. CISC’s inline production test equipment is built around this single pass approach, keeping the line running at the speed of the chip and the web rather than the speed of the encoder.
Encoding RAIN and NFC
Encoding is not only a RAIN activity. NFC tags are encoded too, and the principle is the same even though the data and standards differ. On an NFC tag, encoding might write an identifier or an NDEF record and then personalise and lock it, often with encryption for payment or medical uses. The same discipline applies: write, verify, lock. It helps to keep in mind how RAIN RFID and NFC differ in memory structure and security, because that shapes how each one is encoded.
Security: locking, passwords and encryption
For a lot of products, encoding is also the moment security gets applied. Locking the EPC stops it being altered. Access and kill passwords in the reserved bank control who can change or retire the tag. And for the most sensitive applications, cryptographic features add authentication so a tag, and therefore a product, can be proven genuine rather than merely read.
Building this in during encoding is far more efficient than bolting it on later. When testing, encoding, locking and security all happen in the same production pass, a secured tag is simply the normal output of the line, not an extra downstream operation with its own handling and cost.
Frequently Asked Questions
RFID encoding is the process of writing data, usually the EPC, into an RFID tag’s memory so it carries a specific identity. For RAIN RFID this follows the EPC Gen2 protocol under ISO/IEC 18000-63. Reliable encoding also verifies the write and locks the memory.
The system sends a write command to store the EPC in the tag’s EPC memory bank, then reads the value straight back to confirm it was written correctly. Only after that read back check is the tag treated as properly encoded, and it can then be locked.
Encoding writes the identity into the tag. Locking protects that identity from being overwritten, either reversibly with a password or permanently. Encoding gives the tag its value, locking makes sure the value stays put.
Writing a 96 bit EPC takes around twenty milliseconds, and writing plus locking around twenty five, depending on the chip. Spread across multiple lanes on an inline system, that supports very high throughput without slowing the production line.
Because a write can fail silently and still appear to have worked. Reading the value back and comparing it to the intended EPC is the only way to be sure the encode succeeded. Without it, a fraction of tags ship with missing or wrong identities and nobody notices until much later.
Key Takeaways
- RFID encoding writes a unique identity, usually the EPC, into a tag’s memory so it points to a specific product.
- Done properly it is three steps: write the data, read it back to verify, then lock it so it cannot be changed.
- The read back is the part that makes encoding trustworthy, because writes can fail silently and only verification catches them.
- Writing a 96 bit EPC takes about twenty milliseconds and writing plus locking about twenty five, and these scale predictably across lanes.
- On modern lines, testing, encoding, locking and security all run in a single pass, so every tag leaves the factory verified and secured without slowing production.
Encoding RFID tags at volume and want to see write, verify and lock running in a single pass at production speed? Explore the CISC Knowledge Hub or talk to a CISC engineer.