Blog

You ordered 2000 NFC cards. Each one needs to open a different URL when tapped. How does that actually work? This guide explains exactly what happens inside a programmable NFC card — from chip memory to the moment a smartphone reads it.

What Makes an NFC Card "Programmable"?

A programmable NFC card is not magic. It is a card containing an NFC chip with writable user memory — a small block of storage that can hold structured data, most commonly a URL, contact information, or application-specific records.

When a smartphone or NFC reader comes within range, it reads that stored data and acts on it: opening a webpage, displaying a contact, launching an app, or triggering a system action.

The key distinction from a fixed NFC card:

The data stored on a programmable NFC card can be written, updated, or locked — depending on how it is configured.

Understanding that configuration is the difference between a card that works perfectly for your application and one that creates operational headaches at scale.

The NDEF Standard: The Language NFC Cards Speak

NDEF stands for NFC Data Exchange Format. It is the standardized data structure defined by the NFC Forum that allows NFC devices — cards, tags, smartphones, readers — to exchange information in a consistent, interoperable way.

Think of NDEF as the envelope. Inside the envelope, you put a message. The message has a specific format that any NFC-compatible device can read and interpret.

NDEF Message Structure

An NDEF message consists of one or more NDEF Records. Each record contains:

• TNF (Type Name Format) — defines how the record type is interpreted (Well-Known, MIME type, URI, etc.)
• Type — specifies the record type (e.g., URI, Text, Smart Poster)
• ID — optional identifier for the record
• Payload — the actual data content

The Most Common NDEF Record Types

• URI Record (U): Stores a URL. The most common use case for NFC business cards, marketing cards, and product authentication tags. A smartphone reads the URI record and automatically opens the URL in the browser.
• Text Record (T): Stores plain text with a language code. Used for names, descriptions, or short messages.
• Smart Poster Record (Sp): A composite record combining a URI with optional title, action, and icon. Used for richer NFC interactions.
• MIME Type Record: Stores data in a specific MIME format (e.g., vCard for contact information, application/json for app data).
• Android Application Record (AAR): Triggers a specific Android app when the tag is read. If the app is not installed, redirects to the Play Store.

URL Writing: How a Webpage Gets Into an NFC Card

Writing a URL to an NFC card is a straightforward process — but the details matter, especially at production scale.

Step 1: Prepare the NDEF URI Record

The URL is encoded as an NDEF URI record. The NFC Forum URI record type uses a prefix byte to compress common URL prefixes:

• 0x01 = http://www.
• 0x02 = https://www.
• 0x03 = http://
• 0x04 = https://

So https://prosmartcard.com/member/001 is stored as prefix byte 0x04 + prosmartcard.com/member/001 — saving memory on chips with limited capacity.

Step 2: Write to the Chip's User Memory

The NDEF message is written to the chip's user memory area using an NFC writer — either a dedicated encoding station in a factory, a desktop NFC reader/writer, or an NFC-enabled smartphone with a writing app.

Step 3: Verify the Write

After writing, the card is read back to verify the stored data matches the intended content. In production environments, this verification step is automated and logged per card UID.

Individual URL Encoding at Scale

For projects where each card needs a unique URL — such as https://example.com/member/001, /002, /003 — the encoding process uses a serialized encoding workflow:

1. A data file maps each card UID to its unique URL
2. The encoding station reads the card UID
3. Looks up the corresponding URL in the data file
4. Writes the correct NDEF URI record to that specific card
5. Logs the UID + encoded URL for quality control

This is standard practice for loyalty cards, membership cards, digital business cards, and product authentication programs where each physical card maps to a unique digital identity.

Chip Memory: How Much Can You Store?

The NFC chip determines how much data you can write. For the NTAG series — the most common chips for programmable consumer NFC cards:

For most URL-based applications, NTAG213 is sufficient. A typical URL like https://prosmartcard.com/member/001234 is well within the 144-byte capacity.

Choose NTAG215 or NTAG216 when you need to store:

• Multiple NDEF records in a single tap
• vCard contact data (which can be 300+ bytes)
• Long URLs with tracking parameters
• Application-specific binary data

UID-Based Personalization: The Alternative to NDEF Encoding

Not every programmable NFC application requires writing data to the chip. An increasingly common architecture uses the chip's factory-programmed UID (Unique Identifier) as the card's identity — without writing any NDEF data at all.

How UID-Based Systems Work

1. Each NTAG chip ships from the factory with a unique 7-byte UID (e.g., 04:A3:2F:1B:8C:44:90)
2. The UID is read by the NFC reader or smartphone app
3. The UID is sent to a backend server as a lookup key
4. The server returns the associated data: profile, URL, access rights, loyalty balance, etc.

Advantages of UID-Based Architecture

• No encoding required at card production: Cards ship blank, reducing production complexity
• Dynamic data: The associated content can be updated in the backend without touching the physical card
• Cloning resistance: The UID is factory-locked and cannot be changed (on genuine NXP chips)
• Audit trail: Every tap generates a server-side log entry tied to a specific UID

When to Use UID-Based vs. NDEF Encoding

Write Protection: Locking What Should Not Change

Once a card is programmed, you often need to ensure the data cannot be accidentally or maliciously overwritten. The NTAG series provides several write protection mechanisms:

1. Password Protection (PWD/PACK)

NTAG213, NTAG215, and NTAG216 all support a 32-bit password that can be configured to restrict write access:

• Without the correct password, write commands are rejected
• Read access can remain open (anyone can tap and read the URL)
• Write access requires password authentication first
• The password is stored in a protected configuration page on the chip

This is the recommended configuration for most production deployments: open read, password-protected write. End users can tap and use the card normally. Only authorized systems with the correct password can update the stored data.

2. Permanent Lock (One-Time Programmable)

NTAG chips include lock bits — a set of bits that, once set to 1, permanently prevent any further writes to specific memory pages. This is a hardware-level, irreversible operation.

Once lock bits are set:

• The locked memory pages become read-only forever
• No password, no command, no hardware can unlock them
• The chip will reject all write attempts to locked pages

Use permanent locking when:

• The card data must never change under any circumstances
• You need to guarantee data integrity for product authentication or legal compliance
• The card is a one-time-use credential

3. Configuration Page Protection

Beyond user memory, NTAG chips have configuration pages that control chip behavior (password settings, access control, mirror functions). These can also be locked to prevent tampering with the chip's security configuration.

4. NTAG213 Tag Tamper (NTAG213 TT)

A specialized variant of NTAG213 includes a Tag Tamper feature — a physical loop that, when broken, permanently changes a status bit readable by NFC. Used for tamper-evident packaging, seal verification, and anti-counterfeiting applications where physical integrity must be verifiable via NFC.

Originality Signature: Detecting Counterfeit Chips

A critical security feature often overlooked in NFC card procurement: NXP Originality Signature.

Every genuine NXP NTAG chip contains a factory-programmed ECC (Elliptic Curve Cryptography) signature tied to its UID. This signature can be verified against NXP's public key to confirm the chip is a genuine NXP product — not a counterfeit.

Why this matters:

• Counterfeit NFC chips are a documented problem in the spot market at low price points
• Counterfeit chips may lack proper security features, have inconsistent read performance, or fail originality checks
• For product authentication applications, originality verification is the first line of defense

When sourcing NFC cards for authentication programs, always verify that the supplier uses genuine NXP chips and can provide originality verification as part of the quality control process.

Production Encoding Workflow: What to Specify with Your Supplier

When ordering programmable NFC cards from a manufacturer, the encoding specification is as important as the print artwork. Provide clear answers to these questions:

1. Encoding format: NDEF URI? NDEF Text? vCard? Custom MIME type? UID-only (no NDEF)?
2. URL structure: Single URL for all cards, or unique URL per card? If unique, provide the URL template and serialization logic.
3. Data file: For unique encoding, provide a CSV or database export mapping card sequence to URL/data.
4. Write protection: Open write (no protection)? Password-protected write? Permanently locked?
5. Password: If password-protected, specify the 32-bit password value. Keep this confidential.
6. Verification: Require read-back verification and encoding log (UID + encoded data) as a production deliverable.
7. Chip variant: NTAG213, NTAG215, or NTAG216? Confirm based on data payload size.

Common Mistakes in Programmable NFC Card Projects

• Choosing NTAG216 when NTAG213 is sufficient: Higher cost, no functional benefit for simple URL applications.
• No write protection on production cards: Any NFC-enabled smartphone can overwrite the card data. Always specify at minimum password-protected write for deployed cards.
• Not providing a verification log: Without a UID-to-URL mapping log, there is no way to audit or troubleshoot individual cards after deployment.
• Confusing UID with encoded data: The UID is fixed at the factory. The NDEF data is what you write. They are separate things serving different purposes.
• Assuming all NFC chips are interchangeable: NTAG213 from NXP and a generic 13.56 MHz chip may both be called "NFC tags" but have completely different security features, compatibility, and reliability profiles.
• Not testing with target smartphones: iOS and Android handle NDEF records differently in edge cases. Always test the encoded cards with the actual devices your end users will have.

Rewritable vs. Locked: Choosing the Right Configuration for Your Application

The Bottom Line

A programmable NFC card is only as good as its encoding specification. The chip, the NDEF structure, the URL architecture, and the write protection configuration are not afterthoughts — they are the product.

Get the specification right at the start, and you have a card that works reliably across millions of taps, on every major smartphone, for the entire product lifecycle.

Get it wrong, and you have 10,000 cards that need to be recalled, re-encoded, or replaced.

The specification conversation is where we start every project. Let's start yours.