How to Program NFC Tags and Stickers

How do you handle tools for NFC tag programming?

NFC tags are programmed by writing NDEF-formatted data to the tag's EEPROM memory using an NFC reader/writer — and the right tool depends entirely on how many tags stand between you and freedom. An unprogrammed tag is the saddest object in the supply closet: you tap it, full of hope, and nothing happens. No web page, no animation, not so much as a courtesy buzz. It just sits there being a sticker, which is technically all it was ever contractually obligated to be. Everything that later makes it feel like magic — the tap that opens a menu, authenticates a handbag, or checks someone into a conference — happens in exactly one short write step, the step almost everyone forgets to plan for. One tag is a phone app and thirty seconds; ten thousand tags is a desktop reader, a Python script, and a quiet reevaluation of several life choices. Everything else lives on the spectrum between those two moods.

How do you program a URL record step by step?

Writing a URL record that opens a web page when tapped is the most common NFC programming task by an enormous margin. Here is the ceremony using a desktop ACR122U reader — the workflow applies to any reader with NDEF writing capability; the ACR122U is simply the one everybody already owns and keeps in a drawer.

• Step 1 — Connect the ACR122U reader to your computer via USB. Windows usually recognizes it instantly, a rare and touching display of Windows recognizing anything instantly; macOS and Linux want the ACR driver package installed first.
• Step 2 — Open your NFC writing software. NXP's TagXplorer works well, or the open-source NDEF library with a Python/Java wrapper if you are the kind of person who enjoys that. No judgment; some of our best engineers are.
• Step 3 — Place the NFC tag on the reader. The software should detect it and announce its UID, chip type and available memory — essentially a very small, very boring dating profile.
• Step 4 — Create a new NDEF URI record and enter the full URL, https:// prefix and all. The software automatically selects the URI prefix byte to optimize memory usage, doing you a favor you will never notice or thank it for.
• Step 5 — Write the record to the tag. A successful write is confirmed in under 500 milliseconds — faster than you can feel smug about it. Then test with an actual smartphone, because 'it wrote fine' and 'it works' are two very different sentences.

How do batch encoding workflows work?

Batch workflows automate encoding with a scripted desktop-reader session, because programming tags one at a time is fine for ten and a hostage situation for ten thousand. The script does the boring part; the human keeps the one job humans are still better than scripts at: physically moving small objects.

The pattern is always the same. A script loops through a data source — CSV file, database query or API response — writes a unique URL to each tag, logs the tag's UID alongside the URL it just wrote, and beeps. The operator's entire role collapses to 'hear beep, swap tag, repeat', a job a reasonably motivated golden retriever could nearly do.

1. Step 1
   Feed it a CSV with columns for tag sequence number, URL and any variable data. The script reads row N, writes to the current tag, increments N and waits for the next one. Tireless; never asks for a raise.
2. Step 2
   Log every write operation with timestamp, UID and write status. Future-you, debugging a field failure at 11 p.m., will want to send present-you a fruit basket for this audit trail.
3. Step 3
   Set up audio or visual feedback (beep or LED) on successful write so the operator knows when to swap tags without babysitting the screen.
4. Step 4
   Typical throughput with a trained operator is 200-400 tags per hour using a single desktop reader. Coffee not included but strongly implied.
5. Step 5
   For higher volumes (1,000+ tags per day), escalate to a conveyor-fed inline encoder — or outsource encoding to the tag supplier and reclaim your entire weekend.

What write protection and security options exist?

After programming, you face a genuinely consequential decision: lock the tag against future writes, or leave it open. Lock it and it is tamper-resistant but frozen; leave it and anyone with an NFC phone can overwrite your carefully crafted URL with something regrettable. There is no universally correct answer — only a correct answer for your use case, which sounds like a cop-out and isn't.

• No protection: the tag remains fully writable by anyone, forever. Fine for internal testing and personal tags; terrible for anything a stranger can physically reach.
• Password protection (NTAG21x): set a 32-bit password that must be presented before writes are accepted. Authorized personnel can still update the tag; casual vandals cannot. The Goldilocks option.
• Permanent lock (OTP bits): the NTAG21x lock bits can be set to permanently prevent writes to specific memory pages. This is irreversible — the content is fixed forever, as in heat-death-of-the-universe forever. There is no command to undo it, because there is no undo.
• Dynamic lock bits: allow selective locking of individual memory pages while leaving others writable. Useful for tags that need a fixed URL but updatable metadata.
• Recommendation for most B2B deployments: use password protection rather than a permanent lock. It prevents casual tampering while preserving the ability to update content for campaign changes or URL migrations — a luxury permanent locks explicitly, cheerfully, irreversibly do not offer.

What are common programming errors and how do you avoid them?

Programming errors during batch encoding are costly precisely because they hide: everything looks fine on the bench, and the mistakes surface only after the tags are deployed in the field — a genuinely memorable way to start a Friday. These are the most frequent offenders and their preventions.

• Wrong NDEF format: writing raw bytes instead of formatted NDEF messages produces tags that desktop readers parse happily while every smartphone politely ignores them. Always use NDEF library functions, not raw memory writes.
• URL too long for chip memory: NTAG213 holds ~132 URL characters; your marketing team's URL with its full complement of UTM parameters may not fit. Test the complete production URL, not a shortened demo version.
• Missing NDEF terminator TLV: some low-level writing tools do not append the terminator (0xFE) after the last NDEF record, and without it some phones read corrupted data. It is one byte. Append the byte.
• Skipped verification read: always read back the tag after writing to confirm the data was stored correctly. Memory errors during write are rare — and 'rare' stops being comforting around the ten-thousandth tag.
• Accidental lock: setting lock bits when you meant to set a password — the one error on this list with no undo button, no Ctrl-Z and no support ticket that ends in good news. Double-check the lock configuration before writing; a permanent lock cannot be reversed, and the tag can only be replaced.

How is NTAG 424 DNA SUN provisioning different from plain NDEF programming?

Plain NTAG21x programming writes a static NDEF record — the tag says the same thing on every tap, like a parrot with one line. NTAG 424 DNA's Secure Unique NFC (SUN) message changes the URL on every tap and signs it with an AES-128 CMAC: here's a link, cryptographically notarized, that expires the instant you use it. Provisioning therefore involves keys, counters and a verification backend. Skipping these steps in pilot leaves brands shipping 'authentic' chips that any cloned UID will satisfy — which rather defeats the purpose of buying the expensive chip.

• Five AES-128 application keys per chip: Key 0 (Master/Origin), Key 1 (App), Key 2 (Read), Key 3 (Write), Key 4 (Change). Most production deployments only program Keys 0 + 2; the rest stay at default unless your application demands tiered access. Each is 16 bytes of 'do not lose this'.
• Secure Dynamic Messaging (SDM): the on-chip feature that injects the rotating PICC data + CMAC into the URL on each tap. SDM enables confidentiality + integrity without a preceding mutual-authentication round trip — that's why a smartphone can verify with one tap, no app. It is a magic trick, and like all magic tricks it is just math you can't see.
• Two provisioning paths: (1) NXP Trust Provisioning Service — chip-individual AES keys derived from Master keys in FIPS 140-2 Level 3 HSMs at NXP's secure factory, delivered as encrypted key files; (2) post-issuance encoding — you receive default-key chips and program your own keys via a Change Key command. Trust Provisioning is preferred for high-volume luxury / DPP programs; post-issuance is fine for medium-volume marketing.
• URL template at encoding time: pre-set the SDM URL template (`https://brand.com/v?picc={picc_data}&cmac={cmac}`), the SDM read counter file, and tamper status file (for NTAG 424 DNA TT). These three settings are what the chip dynamically populates on each tap — get the template wrong and your verification backend has literally nothing to validate.
• Backend verification stack: your authentication endpoint must store the per-chip Key 2 (AES-128), recompute the CMAC over the PICC data, compare to the chip's signature, and reject taps where the read counter goes backwards (replay attack). Open-source SDKs from sweetTango (Python), Klingele (Node) and the NXP TapLinx SDK (Java) are the common starting points.

FAQ