What happens when an NDEF message exceeds the tag?
A well behaved tool checks the available space first and refuses, telling you the message is too large. A tool that does not check starts writing and stops when the memory runs out, leaving a tag holding a partial message that reads as corrupt rather than as empty.
What should happen
The tag declares how much space is available for content, and a tool that reads that figure before writing can compare it against the message and stop.
You get an error saying the content does not fit, the tag is untouched, and nothing is lost. This is the normal outcome and it is what any tool worth using does.
What sometimes happens
The write starts and runs out of room partway through.
The result is worse than a failure, because the tag now holds the beginning of a message with no proper ending. A reader sees a structure that claims a length it cannot deliver, and reports the tag as corrupt or unreadable rather than as empty.
Recovering means reformatting, which works if the tag is not locked. A tag that was locked before this happened is finished.
The same failure from a different cause
Pulling the phone away mid write produces an identical outcome, and it is far more common than running out of space. Both leave a partial message, both read as corrupt, and both are why a write should be verified rather than assumed.
How to make it fit
Shorten the URL first. It is free, it costs nothing per tag, and it is usually enough. A redirect at your own domain turns a long address with parameters into a handful of characters.
Then remove records. A tag with a URL and two fallbacks is carrying three headers, and dropping the ones you cannot justify recovers real space.
Then move content off the tag. If a vCard does not fit, a link to a contact page does, and it gains the ability to be corrected later.
Only then buy a larger tag, since it is the option that costs money per unit and it is rarely the one you need.
Avoiding it in production
Write one tag from the batch before writing the rest. Read it back, confirm the content is complete, and only then run the batch.
This catches capacity problems, record type mistakes and tag family surprises in a single step, and it takes a minute. Discovering that a thousand tags hold truncated content after they have been applied is the alternative.
Frequently asked questions
Can I recover a tag left holding a partial message?
Reformatting recovers it, provided the tag was never locked. The memory itself is undamaged and the problem is a structure that claims more than it contains.
Will the tag tell me how much space is left?
The tag reports its available content space and a reading tool will show it. That figure is the one to plan against rather than the capacity printed on the packaging.
Does a failed write damage the tag?
No. Nothing physical is affected, and the memory can be rewritten. The exception is a locked tag, where a failed write leaves whatever state it reached, permanently.
Is a bigger tag always the answer?
It is the last answer rather than the first. Shortening the URL, removing surplus records and moving content to a server all cost nothing per unit and usually solve it.