Tapping a stranger's NFC business card hands them close to nothing about you. What lasts is what the cardholder published, because the tap ends at a web page anyone with the address can open.
The tag is a passive piece of memory with no power of its own. Your phone supplies the energy, reads what is stored, and acts on it.
From there it is an ordinary web page with ordinary web page consequences.
The privacy story of an NFC business card belongs to the person who handed it out, not to the person who tapped it.
What the tag knows about you, and what it knows about itself
The NFC Forum describes NFC as a contactless interface at 13.56 MHz where one side can transmit power over the connection, which is what allows a tag to work with no battery in it.
What the tag holds is an NDEF record, and on a business card that record carries a web address. The reading device takes the address and acts on it. Nothing in either the NFC Forum's material or Android's documentation describes a return path that writes anything about you back into the card.
That is an absence in the documentation rather than a law of physics, and it settles the fear that a tap hands something about you back to the card.
Then the complication.
Some tag chips can count themselves. NXP's data sheet for the NTAG213, NTAG215 and NTAG216 documents an NFC counter that increases a 24 bit value on the first valid read command after the tag is powered by a radio field, and a configuration bit decides whether it runs at all. The listed default is off.
Each chip also carries a unique 7 byte serial number, programmed and write protected during production.
The same chips can mirror both of those into the web address stored on the tag. NXP calls it the ASCII mirror function, and it splices the serial number and the counter value into the stored address, so the page the phone opens receives them without anyone typing anything.
That tells the page which physical card this is and how many times that card has been read. It does not tell the page who read it.
Both the counter and the mirror stay off unless whoever programmed the tag switched them on, and whether a particular card is configured that way is not visible from the outside.
Range is small and the two authoritative figures disagree politely. The NFC Forum gives a typical range of up to 2 cm. NXP gives the operating distance for these chips as up to 100 mm, depending on parameters such as field strength and antenna geometry. One is a working figure, the other a chip maximum under favourable conditions.
Haselsteiner and Breitfuß, writing at Philips in 2006, put rough eavesdropping distances at about 10 m for a device sending in active mode and about 1 m for one in passive mode. They state that such numbers hold only for one set of parameters and cannot be turned into general guidance.
The same paper concludes that NFC by itself provides no protection against eavesdropping or data modification. Which matters less than it sounds here, because what an eavesdropper would capture is a public web address the cardholder is handing out on purpose.
Your phone is the strictest gate in the chain
On Android, the tag dispatch system parses the tag, wraps the address and payload into an intent, and starts an activity.
On iPhone, Apple documents that the system reads NFC data without an app and shows a notification each time it reads a new tag, delivering the tag data only after the person taps that notification, and prompting for unlock first if the phone is locked.
It refuses to read at all when the device has never been unlocked, when a reader session is running, when Wallet or the camera is in use, or in airplane mode, and Apple puts the hardware floor at iPhone XS and later.
Every one of those is a consent gate the reader already has and has probably never noticed. Scanning an NFC business card on iPhone covers the device behaviour itself, and if your real question is how any of this gets counted, that belongs to NFC business card lead capture.
What the page learns the moment it opens
The page is open now. It is a website like any other website, and it sees what any website sees.
Without anyone doing anything, that is the IP address and the coarse location derivable from it, the browser's own details, and whatever the address itself carries.
The ICO uses the term link decoration for extra information added to a URL that does not change where the link goes but passes more to the destination than navigation requires. That is exactly what the tag's own mirror function does.
The referrer is the one worth getting right. MDN defines the Referer header as carrying the address of the page that contained the link, and browsers default to a policy that sends the full path and query only within the same origin.
Follow that definition through and a tap has no containing page to report, because the navigation starts from a notification rather than from a link on a page. That is why an owner who wants to tell taps apart from typed visits puts a marker in the address instead.
Then there is whatever the owner installed. The ICO describes a tracking pixel as a small piece of code, usually an image file, whose purpose is to make the browser contact a server so the server can record that a page was viewed.
Meta's own documentation lists what its pixel sends: the contents of HTTP headers, which includes the IP address, browser details and referrer, plus the pixel identifier and Facebook cookie, buttons clicked, and form field names.
Google states that Analytics does not log or store individual IP addresses from EU, Swiss or UK users, and that for that traffic the address is used only to derive location before being discarded. That statement is scoped to those regions.
What regulators say about analytics and pixels
Neither the ICO nor the EDPB has published guidance written specifically for NFC tags or digital business cards. The ICO's rules on storage and access technologies are technology neutral, and a card page is a website, so they reach it the same way they reach any other page. They address whoever runs the page, not the person who tapped.
The ICO allows analytics without consent only through a narrow exception for statistical purposes, which it describes as being about how a service is used, not about who uses it. Relying on it requires clear information and a simple means of objecting, free of charge.
Source: Information Commissioner's Office, captured 2026-08-06.
Three things sit on the far side of that line, where consent is required: logs of individual visitors, connecting a visitor identifier to site activity, and profiling based on IP address or pages visited. Advertising purposes are never exempt, and the ICO's list there runs through ad measurement, frequency capping, market research, product improvement and debugging.
One line in that guidance speaks to the fear that a card page pins down where you were. Coarse location at city or region level that does not allow anyone to be identified is listed as likely to sit inside the exception, so a card page deriving a city from an IP address is not the same animal as a location fix.
A card platform that offers tracking pixels is a platform whose card pages can carry them.
European regulators go further on mechanism. The EDPB's guidelines on the technical scope of the ePrivacy rule treat delivering a tracking link or pixel to a device as storage, and collecting the identifier back as gaining access.
They add that tracking relying on the IP address alone can fall under the same rule where the address originates from the person's own equipment, and then say directly that applicability does not automatically mean consent is required.
None of this is new ground for the law. GDPR Recital 30 already contemplates IP addresses, cookie identifiers and radio frequency identification tags being combined into profiles that identify a person. It is a recital rather than an operative article, and it tells you the concern was anticipated.
The exposure belongs to whoever handed out the card
Turn it around. Four mechanisms carry the durable half of this, and every one of them is a decision the cardholder made.
The page is public and it persists. Anyone with the address opens it, without an account, for as long as it exists. That is the design, and it is why the card works at all. The wider rules that apply to handing out NFC cards are their own subject.
Predictable addresses invite enumeration. OWASP notes that applications frequently use predictable values to reference objects, and that sequential identifiers make enumeration trivial while leaking information such as total record counts and creation order. A card address that counts upward is a card address a stranger can walk.
A shortener puts another company in the path. Bitly's privacy notice lists what it collects on link interactions: the IP address and the location derived from it, the referring website or service, the time and date of each access, device settings such as browser, operating system and language, and cookies. Every tap passes through that before it reaches the page.
Short links have a second property worth knowing. Georgiev and Shmatikov showed in 2016 that the space of five and six character tokens used by URL shorteners is small enough to scan by brute force, which made cloud resources meant for a few collaborators effectively public.
Their study was about cloud storage and maps, not business cards. The token space is the part that carries over.
Search indexing is a switch, and the obvious lever is the wrong one. Google will drop a page from Search entirely when it carries a noindex rule, regardless of who links to it, but only if robots.txt does not block the crawler from seeing that rule in the first place. Blocking the crawler is how a page you wanted hidden stays listed.
Both directions of a tap, side by side
The two columns below are the same tap. They are not the same kind of event.
| The person who tapped | The person who handed out the card | |
|---|---|---|
| What is disclosed | An IP address, browser details, and whatever the address carries, at the moment the page loads | Name, role, contact details, and anything else on the card, published in full |
| Who receives it | The page, plus whatever the owner installed on it and whatever sits in the path | Everyone. No account, no permission, no request |
| How long it lasts | As long as the page's own records are kept | As long as the page exists |
| Who decides | The phone, then the reader, at every step | The cardholder, once, before printing |
| What ends it | Closing the tab ends the visit, not the page's record or anything it stored | Taking the page down |
One column is momentary and mostly local. The other is published and durable, and it stays that way whether or not anybody ever taps.
That asymmetry is the whole subject. What a recipient keeps afterwards, once they have saved the contact, is a separate map worth reading in where digital business cards are stored.
What to leave off a card, and what a handoff actually needs
The contact file a recipient saves is a vCard, and the format is generous. RFC 6350 defines properties for the obvious things and also for a photo, a postal address, an organisation, free text notes, a geographic position and a public key.
Generous is not the same as required. The question worth asking before a print run is which of that a handoff at a conference actually needs, because everything else is being published rather than exchanged.
| Field | What a handoff needs it for | What publishing it means |
|---|---|---|
| Name and role | The reason the exchange happened | Nothing you were not already saying out loud |
| Work email and phone | The next message, the next call | A permanent public route to your inbox |
| Personal mobile | Rarely anything, at a conference | A personal number on an open page for as long as it is up |
| Postal address | Deliveries, and little else | A home location if the address is a home |
| Photo | Recognition after a busy day | A face attached to the rest of the page |
| Free text notes | Context you could say in person | Whatever you wrote, to whoever finds it |
Put nothing on the card you would not put on a public web page, because that is what it is.
The checks worth making on each side
If you just tapped someone's card
Read the address before giving the page anything. Closing the tab ends the visit, but it does not clear whatever the page put on your device and it does not touch the record the page already kept.
Anything you type is a separate decision from the tap that got you there. If the destination looks off, that judgment is its own skill, covered in NFC business card phishing, and the broader safety question is answered in are NFC business cards safe.
If you are about to hand out fifty cards
Read the address written on the tag before the print run, not after. Programming an NFC tag covers how to check what is actually on it.
Keep the destination on a domain you control, and decide deliberately whether a shortener belongs in the path, knowing it logs every visit.
Decide whether the page should appear in search results, and if it should not, set noindex without blocking the crawler that needs to read it.
Do not ship a sequential address. If card number 4,101 is yours, card 4,102 belongs to somebody else and anyone can count.
Know whether your platform's analytics describe how the page is used or who used it, and whether the page gives visitors the clear information and the simple free objection the ICO describes.
If your real question is vendor assurance rather than page behaviour, that is a different checklist, and it is in the most secure digital business card.
A Zapped card is a public web page by design, so a recipient opens it in any browser with no app to install and no account to create, and on the Professional plan a card can be protected with a password.
Analytics history is held for 60 days on Free, 185 days on Starter and 365 days on Professional, which is a stated ceiling on how long anything is kept. The plans are laid out in the pricing section.
What this changes
The person who tapped can stop worrying about the tap and start reading pages, which is the same skill every link on the internet already asks for.
The person holding the box of cards has three decisions to make before Thursday: the domain the card lives on, whether the page belongs in search results, and what goes on the card in the first place.
The tap is not where privacy is decided. Publishing is.
Sources
All pages checked 2026-08-06.
Standards and platform documentation
- NFC Forum, NFC technology overview
- NXP, NTAG213/215/216 product data sheet, Rev. 3.2
- Android developers, NFC basics
- Apple Developer, Adding support for background tag reading
- MDN, Referer header
- MDN, Referrer-Policy
- Google Search Central, Block search indexing with noindex
- IETF RFC 6350, vCard Format Specification
Security research
- Haselsteiner and Breitfuß, Security in Near Field Communication (NFC): Strengths and Weaknesses, 2006
- Georgiev and Shmatikov, Gone in Six Characters: Short URLs Considered Harmful for Cloud Services, arXiv:1604.02734, 2016
- OWASP, Insecure Direct Object Reference
Regulators
- ICO, What are storage and access technologies?
- ICO, What are the exceptions?
- EDPB, Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, Version 2.0
- GDPR Recital 30, Online identifiers for profiling and identification
Product sources
