NFC Business Card: The Chip Only Holds a URL

The chip in a typical NFC business card is an NTAG213. It has 144 bytes of user memory. A realistic vCard — name, job title, city, email, personal site, GitHub, LinkedIn, Mastodon — comes to about 390 bytes. It doesn't fit, and it isn't close.

So the card doesn't carry your contact details. It carries a link to them. Almost every NFC business card on the market writes a single NDEF URI record — roughly 20 bytes for a short URL — and everything a person sees after tapping is fetched from a web page you may or may not control. The metal is a keychain for a URL.

That one fact reorganizes the whole buying decision. Card stock, finish, and chip generation are commodity choices. The URL is the product.

What's Actually Written to an NFC Business Card#

NFC tags don't store "contacts" or "profiles." They store an NDEF message — NFC Data Exchange Format, the payload structure defined in the NFC Forum's technical specifications. An NDEF message is a list of records, and each record has a type.

For business cards, two record types matter:

• A URI record (RTD_URI). A compact, well-known record type that holds a web address. The spec squeezes it further with a one-byte prefix code: 0x04 stands in for https://, so https://devbio.me/priya only costs 15 bytes of payload plus 5 bytes of record overhead.

• A MIME record holding text/vcard. This writes the contact card itself onto the chip, with no network round trip at all.

Android's NdefRecord reference documents both shapes, and Apple's Core NFC framework reads the same structures. Modern iPhones and Android phones both surface a URI record as a tap-to-open banner with no app installed — which is exactly why vendors favor it.

The 144-Byte Wall#

Here is the arithmetic that vendors leave out. Take a plausible developer vCard, in the vCard 3.0 shape most phones still prefer:

BEGIN:VCARD
VERSION:3.0
FN:Priya Raman
N:Raman;Priya;;;
TITLE:Frontend engineer building design systems
ADR;TYPE=WORK:;;Bengaluru;;;;
EMAIL:[email protected]
URL:https://priya.dev
URL;TYPE=GITHUB:https://github.com/priyaraman
URL;TYPE=LINKEDIN:https://www.linkedin.com/in/priyaraman
URL;TYPE=MASTODON:https://hachyderm.io/@priya
URL;TYPE=DEVBIO:https://devbio.me/priya
END:VCARD

With the CRLF line endings RFC 2426 requires, that's 390 bytes. On an NTAG213 you have 144. You're 246 bytes over before adding a phone number or a photo.

Trim the vCard hard — name, one email, one URL — and it will fit. But the version that fits is not the version worth handing to anyone. That's the trade the URL record exists to avoid.

NTAG213 vs 215 vs 216: What the Extra Money Buys#

NXP's NTAG213/215/216 product datasheet (rev. 3.2) states the numbers plainly: these are NFC Forum Type 2 Tag compliant ICs with 144, 504, and 888 bytes of user memory respectively.

If a vendor won't tell you which chip is in the card, assume NTAG213. It's the cheapest, and for a URL-based card it is genuinely sufficient — 124 bytes of headroom on a 20-byte record. Paying up for an NTAG216 only makes sense if you intend to write the contact card itself onto the tag.

URL on the Chip vs vCard on the Chip#

These are two different products that look identical in a card sleeve.

A vCard written to the chip is honest in a way the URL version isn't: what the recipient saves is exactly what you wrote, forever, and it works in an elevator. The cost is that "forever" includes the job title you no longer hold. Our breakdown of why vCard 3.0 still beats 4.0 on real phones covers the format choice if you go this route.

The URL version is editable — but only by whoever controls the URL.

Who Controls the URL Controls the Card#

This is the part that should drive the purchase, and almost no roundup mentions it. When an NFC business card ships with a vendor-hosted profile, the URL on the chip looks like vendor.example/u/a7f3k2. That string is burned into physical objects you've paid to print.

The test is simple: if you stopped paying, would the cards in your wallet still work? If the answer is no, the chip isn't the thing you bought — a subscription is. That's the same trap the Bento.me shutdown sprang on people whose links pointed at a platform rather than a domain, except printed cards can't be edited after the fact.

Put a domain you own on the chip and the lock-in disappears. Pointing a custom domain at a developer profile takes about ten minutes, and it's the single highest-leverage decision in this entire purchase.

Claim a handle before you order cards — devbio.me

How to Test a Card Before You Order 500#

NFC business cards are sold on finish and feel; vendors rarely publish what they actually write to the tag. You can read it yourself in about two minutes.

1. Install an NFC reader app. NFC Tools (iOS and Android) reads raw NDEF records. The open-source nfc-tools suite does the same from a desktop with a USB reader.

2. Tap the sample card and open the Read tab. You'll see the record type — URI or MIME/text/vcard — and the exact payload.

3. Check the chip model. The app reports it (NTAG213, 215, 216) along with total and available bytes.

4. Look at the URL itself. Is it on the vendor's domain or yours? Does it contain an opaque ID you can't change?

5. Check whether the tag is locked. Type 2 tags can be permanently write-protected. A locked tag can never be repointed — which is fine if the URL is yours and terrible if it isn't.

Order one sample card before the bulk run. A vendor who won't sell a single unit is telling you something.

Making the URL Worth Tapping#

Once the chip is just a pointer, the whole question becomes what loads on the other side. A static page with your name and four social icons is a worse business card than a paper one, because it needs a network connection to be equally useless.

What earns the tap is a page that's current. On a developer profile, a handful of endpoints do that work — and because they're plain HTTP, you can verify each one before printing anything:

• /{username} — the page the chip's URL points at.

• /{username}/bio.vcf — a vCard 3.0 file served as text/vcard with a content-disposition: attachment header, so phones offer to save the contact. This is how you get the offline-contact benefit and keep it editable: the file is generated on request, not frozen at print time.

• /{username}/qr — an SVG QR code for the same destination, so one identity covers both the tap and the scan. It takes size (128–1024) and hex fg/bg parameters, which matters when a printer asks for vector artwork.

• /{username}/bio.json — the same profile as JSON, if you want to render it somewhere else.

That vCard endpoint is the detail worth pausing on. It gives you what a chip-written vCard gives you — a real contact file the recipient keeps — without the part where your job title is frozen at print time. The card points at a URL; the URL hands over a fresh vCard.

Set up the handle before the print run — devbio.me

For the wider decision about what belongs on that page, our guide to replacing paper cards with one link covers the layout, and the Blinq vs HiHello comparison shows where the dedicated card apps stop on their free plans.

Key Takeaways#

• An NTAG213 holds 144 bytes. A realistic vCard 3.0 is about 390 bytes, so nearly every NFC business card stores a ~20-byte URL instead of your actual details.

• Because the chip is a pointer, the URL is the product — and a vendor-hosted URL means printed cards you can't repoint if the subscription or the company ends.

• Put a domain you own on the chip, then serve a vCard from that domain instead of burning one into the tag. You get the offline contact file and the ability to change it later.

• Read a sample card with NFC Tools before a bulk order: check the record type, the chip model, the URL's domain, and whether the tag is locked.