What is NDEF, and why does every readable tag use it?
NDEF, the NFC Data Exchange Format, is a small container that says what a tag holds as well as holding it. A tag written in NDEF is understood by any compliant reader, including the one built into the operating system. A tag written without it holds bytes only its own software can interpret.
The problem NDEF solves
A tag is a small block of memory. Without a convention, the bytes in it are meaningless to anyone who did not write them: is this a web address, a temperature reading, an identifier, or noise?
NDEF supplies that convention. It wraps content in a structure that declares what the content is, so a reader that has never seen this tag before can still decide what to do with it.
The shape of a message
An NDEF message is a sequence of records. Each record carries a small header describing what kind of thing it is and how the type should be interpreted, followed by the payload itself.
That header is the entire point. It is what lets a phone see a record and conclude "this is a web address" rather than "these are forty bytes". Records of well known kinds are handled by the operating system without any application involvement, which is why tapping a tag can open a browser on a device where nothing was installed for the purpose.
What a tag without NDEF looks like
It looks broken, which is the practical problem.
The phone detects the tag, identifies its technology, and reports that there is nothing to act on. To the person tapping, that is indistinguishable from a failed read, even though the read succeeded perfectly and the memory may be full of data.
This accounts for a large share of the "my phone sees the tag but nothing happens" reports. The radio side worked. There was simply nothing in a format anything could interpret.
What the container costs you
Bytes. The structure has overhead, and on a small tag that overhead is a meaningful fraction of what you paid for. A tag advertised with a given capacity offers less than that for your actual content, and the shortfall grows with the number of records.
Which leads to a rule worth applying: prefer one record over several. A single web address in one record leaves more room and reads faster than the same information split across a link, a title and a note, because each extra record adds header bytes the reader must read.
The exception is deliberate redundancy, such as adding a plain text record so that something readable appears on platforms that ignore the primary record type. That is worth the bytes.
Frequently asked questions
Do I have to use NDEF?
Not technically, but for anything read by someone else's phone the answer is yes in practice. Without it you would need to ship an application that knows your memory layout, which defeats the purpose of putting a tag on a poster.
Does every phone read NDEF the same way?
The parsing is the same, the reaction is not. Both platforms read the container identically and then apply their own rules about which record types trigger an action, which is where behaviour diverges.
Can a tag hold NDEF and other data at the same time?
On many chips yes, since NDEF occupies a defined area and the rest of the memory can hold whatever you like. Only the NDEF part will be understood by a generic reader, so anything outside it needs your own software.
Why does my tag show less free space than advertised?
Part of the memory holds the structure that describes the tag itself, and the NDEF container adds its own overhead. Both are deducted before your content, and the difference is normal rather than a defect.