How to Program NFC Tags and Stickers

How do you handle tools for NFC tag programming?

A blank NFC tag is, briefly, the most disappointing thing you can hold to a phone: you tap it, and nothing happens. No web page, no animation, no sign it is anything but a sticker. Everything that later makes the tag feel like magic — the tap that opens a menu, authenticates a handbag, or checks someone into an event — is added in one short write step, the part of the rollout almost everyone skips in the planning. This is that step. NFC tags are programmed by writing NDEF-formatted data to the tag's EEPROM memory using an NFC reader/writer. The choice of tool depends on volume: smartphone apps for one-off programming, desktop readers for batch operations.

How do you program a URL record step by step?

The most common NFC programming task is writing a URL record that opens a web page when tapped. Here is the workflow using a desktop ACR122U reader, which applies to any reader with NDEF writing capability.

• Step 1 — Connect the ACR122U reader to your computer via USB. Install the driver if prompted (Windows may auto-detect; macOS and Linux require the ACR driver package).
• Step 2 — Open your NFC writing software. For the ACR122U, NXP's TagXplorer or the open-source NDEF library with a Python/Java wrapper works well.
• Step 3 — Place the NFC tag on the reader. The software should detect the tag and display its UID, chip type and available memory.
• Step 4 — Create a new NDEF URI record. Enter the full URL including https:// prefix. The software will automatically select the URI prefix byte to optimize memory usage.
• Step 5 — Write the record to the tag. A successful write is confirmed in under 500 milliseconds. Test the tag with a smartphone to verify the URL opens correctly.

How do batch encoding workflows work?

When programming hundreds or thousands of tags for a campaign or product line, manual one-by-one encoding is impractical. Batch workflows automate the process using scripted desktop reader sessions.

A typical batch encoding script loops through a data source (CSV file, database query or API response), writes a unique URL to each tag, logs the tag UID alongside the written URL and sounds an audible confirmation. The operator places tags on the reader one at a time, and the script handles encoding and logging automatically.

1. Step 1
   Use a CSV file 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 tag.
2. Step 2
   Log every write operation with timestamp, UID and write status. This audit trail is essential for quality control and troubleshooting.
3. Step 3
   Set up audio or visual feedback (beep or LED) on successful write so the operator knows when to swap tags without watching the screen.
4. Step 4
   Typical throughput with a trained operator is 200-400 tags per hour using a single desktop reader.
5. Step 5
   For higher volumes (1,000+ tags per day), consider a conveyor-fed inline encoder or outsource encoding to the tag supplier.

What write protection and security options exist?

After programming, you must decide whether to lock the tag against future writes. This is a critical decision that affects tag security, flexibility and operational recovery options.

• No protection: The tag remains fully writable. Anyone with an NFC phone can overwrite the content. Suitable for internal testing and personal tags only.
• Password protection (NTAG21x): Set a 32-bit password that must be presented before writes are accepted. The tag remains updatable by authorized personnel but is protected against casual overwriting.
• Permanent lock (OTP bits): The NTAG21x lock bits can be set to permanently prevent writes to specific memory pages. This is irreversible: the tag content is fixed forever.
• 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 permanent lock. This prevents casual tampering while preserving the ability to update content for campaign changes or URL migrations.

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

Programming errors during batch encoding are costly because they may not be discovered until tags are deployed in the field. These are the most frequent mistakes and their preventions.

• Wrong NDEF format: Writing raw bytes instead of formatted NDEF messages results in tags that desktop readers can parse but smartphones ignore. Always use NDEF library functions, not raw memory writes.
• URL too long for chip memory: NTAG213 holds ~132 URL characters. URLs with long UTM parameters or encoded query strings may exceed this. Test the full production URL, not a shortened version.
• Missing NDEF terminator TLV: Some low-level writing tools do not append the terminator (0xFE) after the last NDEF record. Without it, some phones read corrupted data.
• Skipped verification read: Always read back the tag after writing to confirm the data was stored correctly. Memory errors during write are rare but not impossible.
• Accidental lock: Setting lock bits when you meant to set a password — the one error on this list with no undo. 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. NTAG 424 DNA's Secure Unique NFC (SUN) message changes the URL on every tap with an AES-128 CMAC signature — which means provisioning involves keys, counters and a verification backend. Skipping these steps in pilot leaves brands shipping 'authentic' chips that any cloned UID will satisfy.

• 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 long.
• 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.
• 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 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