An NFC tag ships blank. Until something is written to it, a tap does nothing: no page opens, no action runs, the phone simply reports an empty tag. Programming is the single step that turns a blank NTAG213 label or ring into a working credential or link. This guide covers what you are actually writing, the tools for a few tags versus a few thousand, the locking decisions that cannot be undone, and the point at which it is cheaper to have the tags encoded for you.
Table of Contents
What you are writing: NDEF
Most consumer NFC tags — the NTAG21x family in particular — store an NDEF message (NFC Data Exchange Format). NDEF is the container that phones understand: a small wrapper holding one or more records, each with a type. The common record types are a URI (a web address), a text record, a Wi-Fi configuration or a vCard contact.
A URL is the record you will write most often, and it is stored efficiently. NDEF replaces a common scheme with a single prefix byte, so https:// costs one byte rather than eight, and an NTAG213 with 144 bytes of user memory comfortably holds a web address of roughly 120 characters once the record framing is accounted for. Long tracking parameters or a full contact card are what push a design up to NTAG215 or NTAG216. The chip families and their memory maps are set out on the NTAG213 label page; the point for programming is that you are writing a structured message, not raw bytes, and a phone reads only a well-formed NDEF record.
For a handful of tags: a phone app
For ten tags or a quick test, a smartphone is the whole toolkit. Two apps are worth naming because they are real and widely used:
- NFC Tools (Android and iOS) reads, writes and copies tags and supports every common record type.
- NXP TagWriter (Android) offers template-driven writing for URLs, contacts, Wi-Fi and text.
The workflow is the same in either: choose the record type, enter the URL or text, then hold the tag to the phone’s NFC antenna until the write confirms. On Android the antenna is usually in the upper half of the back; on iPhone it is at the very top edge, behind the front camera. iPhones have been able to write tags since iOS 13, through apps built on Apple’s Core NFC; earlier models could only read. After writing, tap the tag with a second phone to prove the record opens as intended — a successful write is not the same as a working tap.
For larger runs: a desktop reader and software
Past a few dozen tags, a phone becomes tedious and error-prone. A USB desktop reader such as the ACR122U or a reader with a free SDK plugs into a computer and encodes tags from a script. Place the tag on the reader, the software reports its UID, chip type and free memory, you create the NDEF record, and write. The gain over a phone is repeatability: a script can loop through a CSV or database, write a different URL to each tag, and log every UID against the value it received, so a field failure later can be traced to a specific write.
Two habits pay for themselves at volume. Read the tag back after each write and compare it to the intended data, rather than trusting that the write returned success. And feed the script your complete production URL, UTM parameters and all — a shortened demo URL that fits is no proof the real one does.
Locking and passwords
After writing, you decide whether the tag can be changed again. NTAG21x chips give you three levels, and one of them is permanent:
- Leave it open. Anyone with an NFC phone can overwrite the record. Fine for personal tags and testing; unwise for anything a stranger can reach.
- Password protection. NTAG21x supports a 32-bit password (PWD) with a 16-bit acknowledge (PACK). A reader must present the password before a protected write is accepted, so authorised staff can still update the tag. This is the right default for most business deployments.
- Permanent lock (OTP lock bits). The static and dynamic lock bytes can be set to freeze memory pages against any further write. This is irreversible: once a lock bit is set it cannot be cleared, and a locked tag with a wrong URL can only be replaced.
Treat a password as a deterrent against casual rewriting, not as authentication. It does nothing to stop a static NDEF record being copied byte-for-byte onto another tag — the copy reads identically. A project that must prove each tap came from a genuine tag needs a cryptographic chip such as the NTAG424 DNA label, which signs every read.
Common mistakes
- Writing raw bytes instead of NDEF. Desktop tools may parse them; phones ignore them. Always write a formatted NDEF message.
- A URL too long for the chip. Measure the encoded record, not the visible URL, and size the chip to it.
- Skipping the read-back. Verify after writing; write errors are rare but not zero across a large batch.
- Locking by accident. Setting lock bits when you meant to set a password is the one mistake with no undo. Double-check the lock configuration before every write.
- Testing the wrong surface. A label reads on the bench and fails on a metal object or through a case. Test on the real surface with the real phones.
When to order tags pre-encoded
In-house encoding suits low volumes and destinations that change often. Beyond that, having the tags encoded before they ship removes the reader, the script and the read-back from your workload, and returns tested tags in a known state. It is the sensible route when the volume is high, when each tag needs a unique serialised URL, or when the chip requires per-chip keys that a phone app cannot set — NTAG424 DNA among them. If that is your situation, the RFID encoding service covers the data format, UID export and sample approval; confirm who owns the destination URL and how the tags are locked before the batch runs.
Whichever route you take, the acceptance test never changes: a real person taps a finished tag with a real phone, and the right thing happens.
