How much tag memory does NDEF overhead consume?
Enough to matter on a small tag and not enough to worry about on a large one. Memory is consumed by the tag structure, by the NDEF container, and by a header on every record, all of it deducted before your content begins.
Three deductions, in order
First, the tag reserves memory for itself: the identifier, manufacturer data, lock bits and the capability container that describes the layout to readers. None of this is available to you and none of it is optional.
Second, the NDEF container adds its own framing so that a reader knows where the message starts and how long it is.
Third, every record inside the message carries a header before its payload.
What reaches your content is the advertised capacity minus all three, which is why a tag sold with a stated capacity reports noticeably less free space in a tool.
Each record costs again
The header is per record rather than per message. Splitting the same content across three records therefore costs three headers instead of one, and the difference is significant relative to a small tag.
This is one of the practical reasons to prefer a single record. The other is read time, since those headers are extra bytes to read, block by block, on a channel where only one side may speak at a time.
When it stops mattering
Quickly, as capacity grows. On a tag with room for a few hundred bytes of content, a header of a few bytes is noise. On the smallest common tags, where you are fitting a URL into a very tight space, the same header can be the difference between a write succeeding and failing.
The consequence is that overhead is a small tag problem specifically. If a deployment is fighting for bytes, the answer is usually a larger tag rather than a cleverer encoding.
Working with margin
Read the free space with a tool rather than calculating from the packaging. Tools report what is genuinely available, and that number is the only one worth planning against.
Then leave room. Content grows: a URL gains a tracking parameter, a name gains a middle initial, a campaign gains a second language. Specifying a tag that fits your content exactly today is specifying a tag that will need replacing.
And remember that a URL can be shortened at the server rather than on the tag. Moving from a long address to a short one is the cheapest capacity gain available and it costs nothing per tag.
Frequently asked questions
Why does my tag report less free space than advertised?
Because the structure, the container and the record headers are all deducted first. The gap is normal and expected, and comparing free space rather than advertised capacity is the way to compare tags.
Does a shorter URL really help?
On a small tag, yes and noticeably. Every character of the address is a byte of payload, and shortening the address is often enough to make a write succeed that was failing.
Is the overhead the same on every tag type?
No, since the structure differs between tag types and chip families. Two tags with identical advertised capacity can offer different amounts of usable space.
Can I avoid NDEF to save the overhead?
Technically yes, and it costs you interoperability. Content outside NDEF is only readable by software that knows the layout, which defeats the purpose for anything read by someone else's phone.