How fast is NFC, and what fits in that speed?
The NFC radio layer runs at a few hundred kilobits per second. That is enough to move a web address, a Wi-Fi credential or a payment exchange in the time your hand stays still. It is nowhere near enough for a file, and the limit you will actually hit first is the tag memory rather than the speed.
The numbers, and why they mislead
The radio layer defines rates of 106, 212 and 424 kilobits per second.
Those figures describe the channel, not the experience. Almost nothing about how a tap feels comes from them, because the payloads involved are so small that transfer time is a rounding error next to everything else that happens during a read.
What actually fits in a tap
A web address is typically a few dozen bytes. A Wi-Fi credential, a phone number, a contact card: hundreds of bytes at most. Even at the slowest defined rate, moving a few hundred bytes takes a handful of milliseconds.
What does not fit is anything resembling a file. A photograph is millions of bytes, and the constraint is not really the speed: a tag holding hundreds of bytes has nowhere to put it. The two limits reinforce each other, which is why the answer to "can I put a picture on a tag" is a flat no rather than a slow yes.
The design that gets around this
Store a short link on the tag and put the payload on a server. It is not a workaround, it is the intended pattern: the tag becomes a pointer that can be repointed later without touching the physical object.
Where the time really goes
Between bringing a phone close and seeing something happen, the transfer of your data is the shortest part. Detection, powering the chip, protocol activation, selecting the tag, reading its structure, then handing the content to the operating system all come first.
Optimising for speed is therefore almost always wasted effort. Optimising for a reliable tap is not.
Why a tap can feel slow
When a read drags, the cause is nearly never bandwidth. Three things account for most of it: the phone is not quite over its antenna, so detection keeps retrying; the tag is at the edge of its coupling range and the exchange restarts; or the content is spread across more bytes than it needs, which the reader has to fetch block by block on a channel where only one side may speak at a time.
Reducing the number of records helps more than anything you can do about speed.
Frequently asked questions
Can NFC transfer a photo or a document?
No. A standard tag holds hundreds of bytes, not millions, so the file has nowhere to go regardless of speed. Phone to phone file transfer over NFC is not how either mobile platform works today either. The usual answer is a link on the tag and the file on a server.
Is a faster tag worth paying for?
Rarely. The differences between defined rates are invisible for payloads of a few hundred bytes, and the perceived speed of a tap is dominated by detection and protocol setup rather than transfer. Spend the money on a larger antenna instead.
Why does writing take longer than reading?
Writing needs the chip to commit data to non volatile memory, which is slower than reading it back, and it needs the tag to stay powered throughout. A tag that reads instantly at the edge of its range can still fail a write at the same position.
Does the amount of data change how long I must hold the phone still?
Slightly, but the dominant factor is the number of separate exchanges rather than the total bytes. A single record of 200 bytes completes faster than five records of 40 bytes each.