The tag accepts writing but the content disappears
The write reported success and nothing persisted. Usually the exchange was interrupted before the tag finished committing. Sometimes the chip bond is failing intermittently. Occasionally you wrote one tag and read a different one, which is easier to do than it sounds.
The interrupted write
Writing takes longer than reading, and the tag needs the field to remain until it has committed what it received.
Lift the phone a moment early and a tool can report success for data it sent while the tag never finished storing it.
The result is a tag that reads as empty, or as holding its previous content, after an apparently successful write.
Rest the phone on the tag, keep it there until the confirmation appears, and wait a beat longer. This one habit removes most occurrences.
A failing tag
A fatigued bond between chip and antenna makes contact intermittently. The tag can power up, respond, accept a write, and lose the connection before committing.
The signature is inconsistency: writing works sometimes, on some phones, in some positions.
Compare against an identical tag that has not been handled. If the fresh one writes reliably in the same position on the same phone, the first is damaged.
Damage does not recover and gets worse. Replace the tag rather than continuing to test it.
You read a different tag
This sounds unlikely and it is common in production, where identical tags sit close together on a bench.
It also happens when an old tag is still stuck under the new one, so the write went to the tag on top and the read answered from the one underneath, or the reverse.
And it happens with a tag in a wallet or badge holder, where a second tag is inside the same object.
Separate written and unwritten tags physically, into two containers, before writing anything. It costs nothing and it prevents a fault that is genuinely confusing to trace.
Confirming what happened
Write one tag, deliberately, holding still until confirmation. Then move it away from every other tag and read it.
If it holds the content, the process is fine and the earlier failure was an interruption or a mixed up tag.
If it is empty again, repeat with a fresh tag from a different part of the batch. A second failure on a fresh tag points at the tool or the phone rather than at the tag.
And read every tag back after writing, as a routine step. A write that reports success and did not persist is exactly the failure a verification pass exists to catch, and it is the one most likely to reach a customer.
Frequently asked questions
Does a tag lose data over time?
No. Data retention far exceeds the life of any deployment, so content that vanished was never committed rather than forgotten.
Why did the tool say it succeeded?
Because it reported sending the data rather than confirming the tag stored it. Reading back is what confirms a write.
Can a phone case cause this?
It can, by weakening the coupling so the exchange breaks partway. Remove the case when writing and hold still.
Should I verify every written tag?
Yes, wherever a bad tag reaching a customer matters. Reading back takes seconds and catches exactly this.