How to Program NFC Tags by Chip Type

 

How to Program a Standard NFC URL Tag in 6 Steps

 

This workflow is for an unlocked NTAG213, NTAG215 or NTAG216 tag and a normal HTTPS URL. The names of buttons vary by app, but the NDEF process is the same.

 

Step	What to do	What to verify
1	Install an NDEF-capable NFC writing app and enable NFC on the phone.	The app identifies the chip and reports that it is writable.
2	Select a URI or URL record, not plain text.	The record type is URI and the address begins with https://.
3	Enter the final destination, including every path, parameter and per-tag serial value.	The complete NDEF message fits the chip, not just the visible URL characters.
4	Tap Write, then hold the phone over the tag until the app confirms completion.	Do not move the phone during the write.
5	Read the tag back and compare the decoded value with the source record.	The URL, serial value and record type all match.
6	Test on the actual Android and iPhone models in scope before deciding whether to protect or lock the tag.	The destination opens correctly with the screen locked or unlocked as required by the use case.

 

If the chip is locked, password-protected, key-protected or not already mapped for NDEF, stop before Step 4. Those are configuration tasks, not ordinary payload writes. For physical format options, compare our NFC tag formats before selecting the chip and antenna.

 

Writing a Tag Is Three Separate Operations, Not One

 

When people say they want to program NFC tags, they may be combining three separate operations. The chip and its current configuration determine whether all three are needed.

 

The first is NDEF mapping or formatting. On an NFC Forum Type 2 tag, a capability container describes how an NFC device may use the data area. NTAG213, NTAG215 and NTAG216 are delivered with an initialized capability container, but their user memory is still ordinary rewritable memory until protection is applied. On MIFARE Classic, NDEF uses the MIFARE Application Directory, NFC sectors and TLV structures defined by the mapping convention; it is not a universal capability container written into a permanent OTP location. Formatting must therefore be treated as chip-specific, and formatting by itself is not always irreversible.

 

The second is writing the payload: an NDEF message containing one or more records, commonly a URI record pointing to a URL. On an unlocked tag, payload writes are normally repeatable. A redirect URL can also keep the physical tag unchanged while the destination behind that URL is updated.

 

The third is configuration and protection: password bytes, access conditions, lock bits, mirror settings, file permissions and cryptographic keys. Some settings are reversible with the correct credential; others are set-only or become operationally unrecoverable if a replacement key is lost. The exact data sheet and memory map for the ordered chip must control this step.

 

Keep the three gates separate in the work instruction: prepare the tag, write and verify the payload, then apply only the approved protection settings. This sequence makes failures traceable and prevents a locking decision from being hidden inside a generic "Write" action.

 

NFC Tag Chip Types Compared Before You Program Them

 

Every serious decision about how to program NFC tags at scale starts with this table, because memory ceiling and platform support are set at the moment of chip selection and cannot be patched later in software.

 

Chip	User memory / practical NDEF capacity	NFC Forum type	Factory NDEF state	Password / key protection	iPhone support
NTAG 213	144 bytes user memory; up to 144 bytes indicated for NDEF	Type 2	Pre-formatted	32-bit PWD / 16-bit PACK	Yes, for a valid accessible NDEF message
NTAG 215	504 bytes user memory; up to 496 bytes indicated for NDEF	Type 2	Pre-formatted	32-bit PWD / 16-bit PACK	Yes, for a valid accessible NDEF message
NTAG 216	888 bytes user memory; up to 872 bytes indicated for NDEF	Type 2	Pre-formatted	32-bit PWD / 16-bit PACK	Yes, for a valid accessible NDEF message
MIFARE Ultralight EV1	48 or 128 bytes	Type 2	Formattable	32-bit PWD / 16-bit PACK	Yes when correctly NDEF-mapped and accessible
MIFARE Classic 1K	1,024 bytes total, roughly 716 available to NDEF once the manufacturer block and 16 sector trailers are deducted	Not an NFC Forum type	Formattable, sector-based	CRYPTO-1 sector keys A/B	No
MIFARE DESFire EV3	2 KB to 8 KB, file-based	Type 4	Application must be created	AES-128 / 3DES, per-file access rights	Core NFC support; NDEF behaviour depends on file setup and access rights
NTAG 424 DNA	416 bytes total, split into a 32-byte capability container, a 256-byte NDEF file and a 128-byte protected data file	Type 4	Pre-provisioned files	Five AES-128 keys, 3-pass mutual authentication	Yes for the accessible NDEF file; secure features require application logic

 

NTAG21x figures, lock-bit behaviour and Type 2 / ISO/IEC 14443 Type A compliance per the NXP NTAG213/215/216 product data sheet. MIFARE Classic 1K structure per NXP data sheet MF1S50yyX (16 sectors × 4 blocks × 16 bytes). DESFire EV3 per MF3D(H)x3. NTAG 424 DNA memory layout per NXP.

 

Two columns decide most projects before any software is chosen: the memory ceiling and the iPhone column. What the table cannot tell you is yield. A correctly specified chip still produces rejects if the encoding step has no verification pass behind it, which is the subject of the second half of this article.

 

NTAG 213, 215 and 216: the Default Choice and Its Real Ceiling

 

NTAG21x is the straightforward option for public URL taps, digital business cards and other applications that need ordinary NDEF behaviour on both Android and iPhone. The chips arrive with an initialized capability container, and a plain URI record can be written with a compatible phone app without building a custom SDK workflow.

 

 

Choose by the encoded NDEF message, not by the visible text alone. NTAG213 provides 144 bytes of user memory. NTAG215 provides 504 bytes of user memory but its initialized capability container indicates up to 496 bytes for NDEF; NTAG216 provides 888 bytes of user memory and indicates up to 872 bytes for NDEF. TLV data, the NDEF record header, the type field and any additional records consume part of that budget.

 

A URI record compresses common prefixes such as https://www. into a prefix code, so the encoded length is not identical to the character count. Do not rely on a fixed URL-length rule. Build the final record, including UTM parameters, serial values and any fallback records, and confirm the byte count in the same encoder that will be used for production.

 

For a digital business card, a short redirect URL is usually more portable than embedding a large vCard. The redirect also lets the destination change without rewriting the tag. The physical format may matter as much as memory; for wallet use, compare blank white PVC NFC cards with sticker and anti-metal constructions.

 

NTAG21x password protection uses a 32-bit PWD and 16-bit PACK. It is an access-control feature, not a cryptographic authenticity mechanism. The password is sent in the clear over the radio link, so it can deter casual rewriting but should not be presented as protection against a determined attacker. Apply password and lock settings only after read-back and handset testing.

 

MIFARE Classic: Writable on Android, Not Supported by Core NFC

 

MIFARE Classic is not an NFC Forum tag type. It is an ISO/IEC 14443-3 Type A card with a proprietary sector, trailer and CRYPTO-1 key structure. NDEF can be stored through the published MIFARE Classic mapping convention, but that convention does not make the chip universally readable by NFC phones.

 

 

Apple lists MIFARE Ultralight, MIFARE Plus and MIFARE DESFire among the MIFARE families supported by Core NFC; MIFARE Classic is not supported. An iPhone should therefore not be specified to read or write the NDEF data stored in MIFARE Classic memory. A separate phone automation that reacts to a scanned identifier is not evidence that iOS can read the stored NDEF payload, and it must not be used as the acceptance test.

 

Android support also depends on the phone hardware and software stack. Test the exact production chip, its key configuration and the target Android models. If members of the public will tap the tag with unknown phones, use an NFC Forum-compatible Type 2 or Type 4 product instead of MIFARE Classic.

 

MIFARE Classic can remain practical in a closed installed system where the readers already support it and phones are outside the requirement. In that case, specify the IC manufacturer, memory size, UID format, sector keys, access bits and reader compatibility explicitly. Our guide to ordering MIFARE 1K tags into an installed system covers the purchasing questions that sit outside ordinary NDEF writing.

 

For iPhone background reading, use a supported tag containing an accessible NDEF URL record and verify the behaviour on the minimum iOS versions and handset models in scope. Do not assume that every record wrapper or protected file will trigger the same background action.

 

Ultralight, DESFire and NTAG 424 DNA: Where Programming Becomes Key Management

 

MIFARE Ultralight EV1 is a Type 2 product with either 48 or 128 bytes of freely available user memory, plus a separate 32-bit OTP area. It can carry an NDEF message when correctly mapped. Its 32-bit password feature is useful for access control, but it is not equivalent to AES authentication.

 

DESFire EV3 and NTAG 424 DNA are Type 4 products with file-based access conditions. Programming may include creating or configuring applications and files, authenticating, changing keys, setting access rights, writing the NDEF file and verifying the result. A consumer phone app is not a substitute for a key-management and provisioning design.

 

NTAG 424 DNA provides a 32-byte capability-container file, a 256-byte NDEF file and a 128-byte protected data file. It supports five AES-128 keys and three-pass mutual authentication. Secure Dynamic Messaging can add dynamic values and a message authentication code to a URL so a server can validate each tap, but the URL template, offsets, key version, diversification method, counter handling and backend validation rules must agree.

 

Factory-default keys are for controlled setup and testing, not for a production authenticity claim. Before release, document who generates the production keys, how each tag receives a diversified value, which party retains recoverable key records, how test credentials are separated from production and how a failed authentication is handled. Do not send live production keys through a general website inquiry form.

 

Six Permanent or Operationally Unrecoverable NFC Changes

 

NDEF formatting is not universally permanent. The items below are the changes that require an explicit release gate. Some alter set-only silicon bits; others remain changeable only while a valid credential is still available.

 

Operation	Effect	Recovery status	Release gate
Type 2 static lock bits	Protect the defined early user pages; on NTAG21x the static-lock coverage is pages 03h through 0Fh.	Set-only; the protected bytes cannot be made writable again.	Final payload approved and read back.
Type 2 dynamic lock bits	Protect additional data areas: 96 bytes on NTAG213, 456 on NTAG215 and 840 on NTAG216, with chip-specific granularity.	Set-only; an incorrect boundary can permanently freeze the wrong pages.	Approved memory map and production-chip trial.
OTP bits or one-way configuration bits	Set chip-specific one-time values or modes.	A programmed 1 cannot be cleared back to 0.	Exact data-sheet address and value reviewed.
Permanent read-only command	Prevents later payload changes on tags and tools that implement a permanent lock operation.	No inverse command after the relevant lock bits are set.	Field trial complete; redirect and service-life plan approved.
LRP mode on NTAG 424 DNA	Enables leakage-resilient primitive operation.	Once permanently enabled, the chip cannot return to AES mode.	Threat model, reader support and backend implementation approved.
Key replacement without a recoverable record	Replaces a factory or project key used to authenticate later changes.	Operationally unrecoverable if every valid copy of the new key is lost.	Key owner, escrow, version and recovery test documented.

 

Locking is not one universal switch. The addresses, coverage and granularity vary by chip. A mixed layout can be viable, but only when the exact memory map is part of the encoding specification. Separate the payload-verification gate from the protection gate, keep pilot tags rewritable, and record the final configuration bytes alongside the batch output.

 

Verifying the Chip Is What the Invoice Says

 

Chip authenticity belongs in incoming inspection whenever the specification depends on an original manufacturer IC. Supported NXP tag families can expose an originality signature written during chip production. Verification software checks that signature against the relevant manufacturer public key; it does not merely compare a UID or product name reported by an app.

 

A tag can still answer ordinary commands while failing originality verification. NXP has stated that counterfeit parts are unsupported and may not provide the security properties expected from the original product (NXP Community).

 

Do not approve clone silicon simply because the use case appears low-risk. A substituted IC can change memory behaviour, locking, endurance, compatibility and traceability as well as security. If a specific chip is named on the purchase order, define the allowed manufacturer and part, the originality-signature sampling plan, the response to a failed check and the evidence delivered with the batch. For a related diagnostic example, see why a cloned sticker can read but still fail in the target system.

 

The MIFARE Classic Security Question, Restated Honestly

 

MIFARE Classic and compatible CRYPTO-1 products should not be selected for a new security-sensitive design on the strength of legacy familiarity. Current research continues to show practical weaknesses in Classic-compatible implementations.

 

A 2024 paper on the FM11RF08S reported defeating its countermeasures and identified a hardware backdoor that can enable recovery of user-defined keys with physical access to a card (Cryptology ePrint Archive). That result is specific evidence about the studied products and techniques; it should not be expanded into an unsupported claim that every manufacturer part has the same backdoor.

 

The procurement conclusion is still clear. Do not describe CRYPTO-1 as a modern cryptographic control, and do not start a new high-consequence access, payment or authentication deployment without comparing an AES-based alternative. An installed low-consequence system may require a managed migration rather than an immediate replacement, but its residual risk and end-of-life date should be explicit.

 

Programming NFC Tags in Bulk: What Changes Above a Thousand Units

 

A phone app writes one tag at a time and usually leaves no controlled batch record. As quantity increases, the important change is not a faster tap; it is the move to a defined input file, automated writing, independent read-back and traceable output.

 

For prototypes and a small pilot, a phone can be sufficient. For repeatable in-house work, use a compatible desktop NFC reader-writer, a controlled data file and software that supports the exact chip commands you need. A tool written for MIFARE Ultralight does not automatically support DESFire or NTAG 424 DNA.

 

For supplier encoding, the purchase specification should define the input schema, fixed and variable records, serial-number rules, UID-to-content correlation, protection bytes, key responsibility, read-back method, failure disposition and delivered mapping-file format. Treat claims such as per-unit verification, line capacity and daily output as quotation items that require documented confirmation for the actual chip and construction.

 

Keep production credentials out of ordinary email and website forms. If secure provisioning is required, agree a protected key-transfer and custody process before samples are encoded. The tag supplier can implement an approved encoding profile, but the application owner remains responsible for backend validation, credential lifecycle and acceptance criteria.

 

Nine Questions to Settle Before the Encoding Run

 

Answer these before the purchase order and sample approval. Each answer changes the chip, payload, provisioning process or acceptance test.

 

#	Question	What it controls
1	Which iPhone and Android models and OS versions must work?	Chip family, NDEF type and device test matrix
2	What is the final encoded payload, including parameters and serial values?	Memory requirement and input-file schema
3	Is every tag identical, or is data variable per unit?	Serialization and UID-to-content mapping
4	Must the destination or payload change during service life?	Redirect design and whether permanent locks are acceptable
5	Does the application make an authenticity or anti-counterfeit claim?	Cryptographic chip, backend validation and originality checks
6	Who generates, transfers, stores, rotates and recovers keys?	Provisioning boundary and long-term maintainability
7	What read-back and functional tests define an accepted unit?	Verification method and failure disposition
8	Which mapping and QC files must be delivered, and in what format?	Traceability and system import requirements
9	How will the ordered IC and physical construction be verified?	Incoming QC, originality sampling and reader performance

 

Copy This NFC Encoding Brief Into Your RFQ

 

Chip and construction	Manufacturer, exact part, memory size, antenna, label/card material, size and mounting surface
Quantity and data mode	Total quantity; same payload on all tags or variable data per unit
NDEF payload	Record type, complete sample value, encoding and maximum byte length
Variable-data input	CSV column names, serial-number rules, duplicate handling and source-file owner
Protection profile	Writable, password-protected, authenticated or permanently locked; include exact addresses and configuration bytes
Keys	Key owner, diversification method, key version, protected transfer method and recovery responsibility
Verification	Read-back rule, originality check, functional tap test, sample size and failure disposition
Device matrix	Required phones, OS versions, readers, mounting surfaces and test states
Deliverables	UID-to-content mapping, QC report, rejected-unit handling and file format

 

Remove live keys and other secrets before sending this brief through a general inquiry channel. Use the first review to confirm the chip, payload and process; agree a protected credential exchange separately if secure provisioning is required.

 

Where This Leaves a Buyer

 

For a standard public URL, start with a supported NTAG21x product, encode the final URI, read it back and test the actual device matrix before applying protection. For an installed MIFARE Classic system, treat phone compatibility and CRYPTO-1 risk as explicit constraints. For DESFire or NTAG 424 DNA, design keys, files, dynamic messaging and backend validation before the production encoding profile.

 

If the chip decision is still open, compare the available NFC tag formats and constructions. If you already have a draft specification, request an NFC encoding specification review and include the non-secret fields from the brief above. Stock samples may be available for qualified projects; confirm availability, shipping cost and the exact IC before relying on a sample offer.

 

FAQ