Writing corrupted the tag
Usually recoverable. An erase followed by a fresh write fixes a tag left in an incoherent state by an interrupted write. The exceptions are specific and rare: a tag whose configuration bytes were altered, and one that was locked while its content was incoherent.
What corrupted usually means
Most often, a message that stops partway. An interrupted write left the tag holding part of a new message, and readers report it as invalid, empty, or truncated.
Nothing is broken physically. The memory holds bytes that do not form a valid message, which is a content problem rather than a hardware one.
Less often it means the tag reads inconsistently, which is mechanical damage rather than corruption and behaves quite differently.
And occasionally it means configuration bytes were written, which is the serious case and the rarest.
The recovery attempt
Erase the tag with a tool that clears content, then read it back and confirm it reports as empty.
If that works, write your content again and verify. The tag was never damaged and a clean starting state was all it needed.
If erasing fails, check whether the tag is locked or password protected, since both refuse an erase in the same way they refuse a write.
If erasing succeeds and the tag still reads as invalid, try formatting it, which rebuilds the structure that marks the area as ready to hold content.
When configuration was touched
The configuration area sets behaviour rather than holding content: mirroring, counters, protection settings and the password.
Writing to it by accident is possible with software that addresses memory directly rather than working through records. Ordinary writing tools do not go near it.
The consequences can be permanent. A protection setting enabled with an unknown key, or lock bits set, cannot be reversed.
If a tag suddenly refuses writing after an unusual tool touched it, this is the likely explanation and there is no route back.
When to stop and replace
When erasing and formatting both fail on a tag that is not locked or protected.
When the tag reads inconsistently in a position where a fresh tag reads reliably, which points at mechanical damage rather than content.
When you have spent more than a few minutes on it. A tag costs cents, and the value of the exercise is knowing which failure you have rather than saving the tag.
Keep one confirmed dead tag aside and labelled. It is the cheapest way to check that your verification step actually detects a bad tag, which is worth knowing before a production run.
Frequently asked questions
Can a normal writing app corrupt a tag?
It can leave an incomplete message if the write is interrupted, and that is recoverable by erasing and rewriting. Ordinary tools do not touch configuration.
Does erasing fix a corrupted tag?
In most cases yes, since the problem is an invalid message rather than damage. Formatting is the next step if erasing is not enough.
Why does the tag read as empty but refuse writing?
Empty and protected are different states that can coexist. Read it for its writability, which is reported separately from its content.
Can configuration damage be undone?
Protection settings and lock bits are permanent once applied. That is why tools which address memory directly should be used deliberately.