Digital business card not saving to contacts? Five real causes

A digital business card is a .vcf file behind a link or QR code. When it scans but nothing gets saved, the file is almost always malformed rather than the phone being at fault — most often a missing structured name field, which iOS silently refuses to import.

We shipped that exact bug ourselves. Our vCard endpoint went out without the N field and we did not catch it until August 2026. The symptom is maddening: scan the code, the contact sheet appears on Android, and on an iPhone you get a card with a blank name and a Save button that produces nothing useful. Nobody reports it, because the person scanning your card assumes they did something wrong and moves on.

Here is what actually breaks, in the order we have seen it break.

What a digital business card is, underneath

Strip away the marketing and there are three moving parts:

1. A vCard file (.vcf) — a plain text format defined in RFC 6350, with one field per line.
2. A URL that serves that file with the right content type.
3. A QR code pointing at the URL, or in some products, containing the whole vCard.

Every failure below sits in one of those three. That is the useful part of knowing the plumbing: you can tell within a minute which layer is broken.

A correct minimal card looks like this:

BEGIN:VCARD
VERSION:3.0
N:Rivera;Dana;;;
FN:Dana Rivera
TITLE:Ceramicist
EMAIL:dana@example.com
URL:https://example.com/dana
END:VCARD

Cause 1: the N field is missing

FN is the display name — "Dana Rivera". N is the structured name — family, given, additional, prefix, suffix, separated by semicolons. Both are required by the spec. Plenty of generators emit only FN, because it is the one users type.

Android's contact importer is forgiving and will fill in from FN. iOS is not. A vCard without N gets imported with an empty name, and an empty-name contact is functionally lost the moment it is saved — it sorts to the top of the list with nothing to search for.

This is a five-second check if you can download your own .vcf and open it in a text editor: look for a line starting N: alongside the FN: line. If only FN: is there, that is your bug.

One wrinkle worth knowing if your name does not split into two Latin words: the N field assumes a family/given split. A single-token name, including most Chinese, Japanese, and Korean names written without a space, has no correct split. Putting the whole thing in the family slot is the least-wrong option and is what most exporters do — but it does mean a card can come out "correct" and still sort oddly on the recipient's phone.

Cause 2: the QR code contains the whole card

There are two schools. Encode a URL, or encode the vCard text itself.

Encoding the vCard directly means it works with no network. It also means every character you add makes the QR denser. A URL is 30-odd characters and produces a sparse, forgiving code. A full vCard with a title, two phone numbers, and an address runs 250 to 400 characters and produces a code that needs good light, a steady hand, and a clean print to scan.

We encode a URL, and you generally should too, for a second reason that matters more than density: a card that points at a live page can be corrected. A card encoded directly into a QR is frozen at the moment you printed it. When your title changes, every business card, conference badge, and window sticker carrying that code is now wrong.

If you want to see the difference, the free QR code generator here will render a code for any URL, and you can compare it against one of the "encode full vCard" generators.

Cause 3: the file is served as the wrong content type

This one only affects the URL approach, and it is invisible until you test on a real phone.

A .vcf served as text/plain or text/html opens as a wall of text in the browser instead of triggering the contact sheet. It has to go out as text/vcard, and it helps to add a Content-Disposition header with a filename so the download has a sensible name.

You can check this without any tools. Open the card link on a phone. If you see BEGIN:VCARD as visible text on screen, the content type is wrong. If the contact sheet slides up, it is right.

Cause 4: unescaped commas and semicolons

vCard uses ; to separate the components of a field and , to separate values within a component. So a job title of "Founder, Studio Nine" is not a job title — it is two values, and what lands on the phone is a truncated "Founder".

Anything a person can type into a field has to be escaped before it goes into the file: backslashes, semicolons, commas, and newlines. Company names with commas and multi-line addresses are where this shows up in practice, which is why it tends to hit exactly the people with the most complete profiles.

Cause 5: line endings

vCard content lines end with CRLF, including the last one. Files written with plain newlines mostly work, right up until they meet a parser that does not tolerate it — older Outlook builds are the usual place people discover this.

It is a one-character difference that nobody can see, which is what makes it worth ruling out last rather than first.

A two-minute test that actually catches these

Skip the desktop preview. It is the layer least likely to break.

1. Send yourself the card link and open it on an iPhone. The contact sheet should appear. Save it, then find it in Contacts and confirm the name is populated.
2. Do the same on an Android phone. Compare which fields survived on each.
3. Print the QR at the size you will actually use — a badge, not a screen — and scan it from about arm's length in ordinary indoor light.
4. Open the .vcf in a text editor and look for N: and FN: on separate lines.

Two phones, because they disagree, and the disagreement is the whole point. If a card imports cleanly on Android and comes up blank on iOS, you have found cause 1 without needing to read a spec.

What a digital card does not fix

It does not make anyone remember you. The advantage over paper is narrow and specific: the data is correct at the moment of the scan, and you can change it afterwards. Everything else — whether the person follows up, whether they can tell what you do — is decided by what is on the page they land on, not by the format.

Which is the argument for pointing the code at a real page rather than a bare contact file. A .vcf gives someone a phone number. A page can show the work, and the contact card can hang off it: on Nameplate, every published page has a /v/ address that returns a vCard and a /q/ address for the QR, so the card and the page are the same object rather than two things to keep in sync. Browse the portfolio templates if you want to see what the landing side looks like.

Common questions

Do digital business cards work without an app?

Yes, if they are built on vCard and a plain URL. Both iOS and Android handle .vcf natively — Apple documents importing them in its Contacts support pages. Products that require the recipient to install something have chosen that, and it is worth asking why before you hand out the code.

Why does my QR code work on my phone but not on someone else's?

Usually density. Your phone has scanned that code a hundred times from six inches away on a bright screen. A stranger scans it once, from a printed badge, at a conference. Test the printed version at real distance before you commit to it.

Should the QR code hold the vCard or a link?

A link, unless you specifically need offline scanning. Links stay editable after printing and produce a sparser, easier-to-scan code. The tradeoff is that a link needs a network connection at the moment of the scan.

Can I change my details after handing out the card?

Only if the QR points at a URL you control. If the vCard is encoded into the QR itself, the printed code is a snapshot and cannot be changed.

Does an NFC card work better than a QR code?

It scans faster where it works, but coverage is not universal and some phones need the reader enabled. Most people who use NFC cards print a QR on the back for exactly this reason.