A contact QR code at a conference. You scan it, your phone says "Add Contact," you tap it, and ninety-nine percent of the time you never think about what just happened. There's a file that moved between those two phones, and that file is probably older than most of the people at the conference.
The vCard. VCF format. And Daniel wrote in with a question that gets right to the heart of why this matters.
Here's what Daniel sent us. He says he's talked before about the surprisingly important details of digital formatting — things like properly formatting international phone numbers. Old standards most people never think about, yet getting them wrong quietly costs businesses leads every day. VCF is another technology in that category. It's been around for decades and remains the universal standard for exchanging contact information. Every time you export a contact from your phone or tap "Add Contact" after scanning a QR code, there's a good chance a VCF file is what's actually being transferred. Now, there are countless apps and subscription services marketing themselves as digital business card platforms — beautiful profiles, analytics, networking features — but at the core, he says, many of them are simply making it easier to distribute a well-formatted VCF file. Once you understand the underlying standard, a lot of the magic disappears, and you gain the ability to create portable, future-proof digital business cards without depending on someone else's platform.
He's not wrong.
He's really not. He wants to know what the VCF specification actually supports beyond name, phone, and email. Which fields are widely supported, which are inconsistently implemented. Formatting quirks, compatibility issues. He wants to know if it's worth maintaining multiple versions of your contact card — trade shows versus conferences versus clients versus personal life — and how you balance memorable with overwhelming. And then the big question: why has this humble file format survived for so long in a world full of proprietary networking apps? Is it static, or is it evolving as fax numbers fade and social networks become more prominent?
That's a lot of good questions.
It is. So let's open up the file and see what's actually inside — and why this boring format refuses to die.
The thing to understand about VCF is that it's the plain text of contact data. That's the thesis. It's not glamorous, it's not new, and that's precisely why it works. Every proprietary platform eventually has to export to VCF because it's the only format every other system accepts. The startups build beautiful interfaces on top, but the interchange layer — the thing that actually moves between phones — is a text file with BEGIN colon VCARD at the top.
A text file you can open in Notepad.
And that's the power. So we're going to do three things today. First, we'll dissect the spec — what's actually in the file, what properties exist, what the formatting rules are. Then we'll look at the messy reality of compatibility — what actually works when these files move between devices. And finally, strategy — how to use VCF deliberately instead of just letting your phone do whatever it does.
And the stakes here are genuinely practical. Understanding VCF is the same kind of technical literacy as understanding international phone number formatting. It's a small thing that quietly pays dividends. You're never locked into a platform.
First, let's get our hands dirty with the spec itself. What can a VCF file actually hold?
Walk me through the anatomy.
Alright. A VCF file starts with BEGIN colon VCARD and ends with END colon VCARD. Inside, you've got property lines. The version line tells you which spec we're dealing with — VERSION colon three point zero, or four point zero. Then you've got the core properties. FN is the formatted name — that's your display name, "Jane Doe." N is the structured name, and this one trips people up because it uses semicolons to separate sub-fields. Family name, given name, middle name, prefix, suffix — all in one line, separated by semicolons.
So N colon Doe semicolon Jane semicolon semicolon semicolon.
Right. Those trailing semicolons are important — they hold the places for middle name, prefix, and suffix even when they're empty. If you skip them, some parsers will shift everything over and suddenly your middle name is being read as your prefix.
That's the kind of thing that breaks silently.
It does. Then you've got TEL with TYPE parameters. TYPE equals WORK, HOME, CELL, VOICE, TEXT, FAX, VIDEO — you can stack them. TEL semicolon TYPE equals WORK comma CELL colon plus one dash five five five dash zero one zero zero. EMAIL is straightforward, same TYPE parameters. ADR is structured like N — semicolon-separated sub-fields for post office box, extended address, street, locality, region, postal code, country. Seven sub-fields in a specific order.
Seven sub-fields. And if you get the order wrong?
Your country ends up in the postal code slot. Nobody notices until they try to mail you something.
So beyond the basics — name, phone, email, address — what else does the spec actually support?
This is where it gets interesting. vCard three point zero, which is RFC two four two six from September nineteen ninety-eight — that's the most widely supported version — supports ORG for organization, TITLE for job title, ROLE for your function within the organization. PHOTO, which can be embedded as base64 or referenced as a URL. BDAY for birthday, ANNIVERSARY, NOTE for free-text notes, URL for a website. You can attach a logo, a sound clip —
A sound clip.
The spec supports attaching audio. I don't know anyone who's ever used it, but it's there. You can include a public encryption key. There's a GEO property for geographic coordinates. There's a CATEGORIES property for tagging contacts. And then vCard four point zero, which is RFC six three five zero from twenty eleven, added IMPP for instant messaging handles, GENDER, LANG for language preference, and the KIND property to distinguish individuals from organizations or groups.
KIND property. So you can mark a contact as an org rather than a person.
Right. And that matters if you're importing into a contact manager that treats people and businesses differently. But here's the thing that really answers Daniel's question about whether the format is evolving. April twenty twenty-four — just over two years ago — RFC nine five five four was published, adding the SOCIALPROFILE property to vCard four point zero. That's a direct response to the rise of social networks. You can now specify a social network handle with a type parameter — Twitter, LinkedIn, GitHub, whatever — and the spec handles it natively.
So the spec is still being updated. The IETF is still publishing RFCs for vCard.
It is. But the evolution is glacial by design. The format's value is stability. Changes come slowly and only when there's broad consensus. SOCIALPROFILE took years to standardize, and even now, support is spotty — but we'll get to compatibility in a minute.
Before we leave the spec, you mentioned encoding. What's the thing that actually corrupts people's data?
The encoding quirk that trips everyone up is the transition from vCard two point one to three point zero. Two point one used something called QUOTED-PRINTABLE encoding for non-ASCII characters. So an accented character — say, an e with an acute accent — would be encoded as equals C three equals A nine. It's a way of representing bytes outside the ASCII range using only printable ASCII characters. vCard three point zero and four point zero switched to UTF-eight.
So if you've got an old contact export from, say, an early two thousands phone, and you open it in a modern app —
You get mojibake. Garbage characters. The app sees equals C three equals A nine and displays it literally instead of decoding it as the accented character. Because it's expecting UTF-eight and getting QUOTED-PRINTABLE. The data isn't corrupted — it's just encoded in a way the modern parser doesn't expect.
And most people would just assume the file is broken.
They would. And there's another encoding trap that's still relevant today. Escaping. Commas, semicolons, and backslashes in property values have to be escaped with a backslash. So if your organization name is "Acme, Inc." you need to write it as "Acme backslash comma Inc." Because commas are also used as list separators within structured properties —
Wait. So a comma in your company name, unescaped, could split your address into an extra field?
Yes. A single misplaced comma can silently corrupt an address or a name. The parser sees the comma, assumes it's a field separator, and everything after it shifts into the wrong slot. And since many apps don't validate on import, you won't know it happened until someone tries to use the contact and the street address is in the country field.
That's the kind of bug that lives for years.
The other big trap is N versus FN. I mentioned this earlier. FN is the formatted display name — what shows up in your contact list. N is the structured name with all those semicolon-separated sub-fields. A lot of apps populate FN automatically from N. But if you only set FN and leave N empty, some contact managers — especially older ones — will show a blank name field or fail to sort the contact correctly. The spec says both are required, but in practice, many exporters set only one.
So if you're hand-crafting a VCF, you set both.
You set both, and you make sure N has the right structure with the right number of semicolons. Even if the middle name and prefix and suffix are empty, those semicolons need to be there.
Alright. So the spec is rich — more properties than most people will ever use, encoding rules that can bite you, structural traps in the name fields. But the spec is not the same as reality. Let's talk about what actually happens when these files move between devices.
The compatibility minefield. vCard three point zero is the safest bet. It's defined in RFC two four two six from nineteen ninety-eight, and it's what almost every phone, email client, and contact manager supports reliably. vCard four point zero is the current standard — RFC six three five zero from twenty eleven — but support is wildly inconsistent. iOS and Android both handle three point zero well. Four point zero features like SOCIALPROFILE, GENDER, KIND — those get ignored or stripped by a lot of apps.
So exporting four point zero is actually less compatible than exporting three point zero.
In many cases, yes. And this runs counter to what people assume. Newer version, better, right? Not here. The newer version has features that the ecosystem hasn't fully adopted. If you want maximum compatibility, you export three point zero.
Which fields are the universal ones?
FN, TEL, EMAIL, ORG, and TITLE are near-universal. You can count on those working everywhere. ADR is pretty well supported, though the structured sub-fields sometimes get flattened into a single string. URL usually works. NOTE usually works. Everything beyond that is a lottery.
What's the worst offender?
PHOTO. Photo support is a mess. Some apps embed the photo as base64 directly in the VCF. Others reference a URL. Some contact managers refuse to sync photos from VCF at all — they'll import the contact but drop the image. And if you're moving between ecosystems — say, exporting from an iPhone and importing into an Android contact manager that expects a different image format or size — the photo just vanishes. No error, no warning.
BDAY and ANNIVERSARY?
Often mangled. Different apps assume different date formats. Some expect YYYY-MM-DD, some expect MM-DD-YYYY, some just give up and store it as a text string. And once it's a text string, your contact manager can't use it for birthday reminders.
So the failure mode here is particularly insidious. It's not that the import fails with an error. It's that the import succeeds and drops data silently.
That's the core problem. A contact exported from one app and imported into another can lose fields without any indication. The receiving app doesn't error — it just discards what it doesn't understand. This is why "it worked on my phone" is not a reliable test of a VCF's portability. You need to open the imported contact and actually check whether every field made it through.
Which nobody does.
Nobody does. They tap import, see the name pop up, and assume everything is fine. Six months later they're searching for the birthday they know they saved, and it's not there.
So given all this, Daniel's question about maintaining multiple versions — is that actually worth doing?
It is, but not five versions. The sweet spot is two or three. A professional card — name, title, organization, work email, work phone, LinkedIn URL, website. A conference card — adds a QR-friendly URL, a short note about what you do, maybe a scheduling link. And a personal card — personal email, personal phone, no work details. That's it. You don't need a separate VCF for every context.
The conference card is interesting. What makes it different from the professional card?
Context. When someone scans your QR code at a conference, they're going to have fifty new contacts by the end of the day. Your card needs to answer "who is this person and why did I scan them?" A NOTE field that says "Helps teams ship faster with better data pipelines" is worth more than your full title and department. It's a memory anchor. The professional card can have the complete details — the conference card is the handshake.
And the balance between memorable and overwhelming?
A good VCF is a handshake, not a resume. Name, one or two contact methods, a URL, and a single line in NOTE that gives context. Everything else is noise. If you put five phone numbers, three emails, and your full mailing address, the person saving your contact doesn't know which one to use. They won't use any of them. Worse, it feels like spam — like you're broadcasting rather than connecting.
It's the most underused field in VCF. A single sentence that says what you do and why someone would want to reach you. Not your job title — your function. "I help companies stop losing leads to bad phone number formatting." That's memorable. "Senior Director of Digital Transformation Initiatives" is not.
One of those sounds like a human. The other sounds like a LinkedIn profile that's been auto-exported.
And that's exactly the problem with most auto-generated VCFs. They dump every field the platform knows about into the file, and the result is a contact card that reads like a database row.
Let's talk about why this format has survived. Daniel's question about that is the one I keep coming back to. In a world where every networking app wants to be your contact manager, why is a text file from the nineties still the foundation?
Network effects and the lowest common denominator. Every proprietary app eventually has to export to VCF because it's the only format every other system accepts. LinkedIn's QR code contact sharing — underneath, it produces a VCF on the receiving phone. The digital business card startups — their "magic" is a well-formatted VCF with a custom URL and maybe a photo. The analytics, the profiles, the networking features — that's the wrapper. The core is VCF.
So the startups are building distribution layers on top of an open standard.
And that's not a bug — it's the moat that keeps VCF alive. The format doesn't need to be better than the proprietary alternatives because every proprietary alternative needs VCF to function. You can't build a contact-sharing app that doesn't interoperate with the existing ecosystem, and the existing ecosystem speaks VCF.
It's the email of contact formats. Everyone has tried to replace email. Nobody has.
Same dynamic. Open standard, universally supported, good enough. The boring technology that outlasts everything built to replace it.
Now, Daniel asked specifically whether the format is static or evolving. You mentioned RFC nine five five four adding SOCIALPROFILE in twenty twenty-four. So it's not static.
It's not static. It's evolving — slowly, deliberately, and only when the need is undeniable. SOCIALPROFILE is a perfect example. For years, people were stuffing social network handles into NOTE fields or custom X-properties. The IETF eventually recognized that social networks aren't a fad — they're a permanent part of how people connect — and standardized a property for them. But it took years, and adoption is still inconsistent.
Will SOCIALPROFILE get broad adoption?
That's the open question. vCard four point zero has been around since twenty eleven, and a lot of the ecosystem is still on three point zero. SOCIALPROFILE requires four point zero. So you've got a chicken-and-egg problem — apps won't adopt four point zero fully until there's demand, and there's no demand because the features aren't widely supported.
Meanwhile, fax numbers are still in the spec.
They are. TEL semicolon TYPE equals FAX is still valid. And I don't think it's going anywhere. The spec is conservative about removing things. Once a property is in the standard, it tends to stay — because somewhere, somebody's contact manager still relies on it.
The backwards-compatibility burden.
Which is also why the format survives. You can open a vCard from nineteen ninety-eight in a modern phone, and it works. Try that with a proprietary format from the same era.
So all of this theory is useful, but let's make it practical. What should someone actually do with this knowledge?
Three things. First, audit your own VCF. Export your contact from your phone right now, open it in a text editor, and look at what's actually in there. Check for the N versus FN trap — do you have both? Verify your photo is embedded as base64 and not just a URL that might break. Confirm your non-ASCII characters survived the export — if your name has an accent and it's showing as equals C three equals A nine, you've got a QUOTED-PRINTABLE problem.
Second?
Create two VCFs deliberately. A professional one and a personal one. Store them somewhere you control — a GitHub repo, a personal website, a cloud drive. Update them when your details change. Don't rely on your phone's auto-export, because your phone is making decisions about which fields to include and which version to use, and those decisions might not be the ones you'd make.
And third?
When you're evaluating a digital business card app, ask one question. What does the exported VCF look like? Ask them to show you the raw file. If the app can't produce a clean, standard VCF — if it's wrapping the data in something proprietary that only works inside their platform — you're renting your contact data. The platform is a trap.
That's a good litmus test. If they hesitate when you ask for the raw VCF, walk away.
The mental model here is simple. VCF is to contact data what plain text is to documents. It's not glamorous, but it's the thing that always works. Understanding it means you're never locked into a platform. You can move your contacts anywhere, and you can give your contact to anyone, and it will work.
One last thought before we wrap — because the future of this format is an open question.
It is. Social profiles are becoming more prominent. Fax numbers are fading. The pressure to modernize is real. But the pattern is clear — proprietary formats come and go, and open interchange standards persist. The next time you see a "revolutionary" contact-sharing app, ask what's underneath the hood. If the answer is VCF, it's not revolutionary — it's a new paint job on a thirty-year-old standard. And that's actually a good thing.
The misconception that most people hold about this topic — and I think it's the one Daniel was circling in his prompt — is that digital business card apps are doing something fundamentally new. They're not. Most of them are polished wrappers around VCF generation and distribution. The underlying file is the same standard that's been around for decades. The innovation is in the user experience, not the interchange format.
And the second misconception — that if a contact imports without errors, all the data came through. Many apps silently drop unsupported fields. A successful import can lose photos, structured names, or custom properties without any warning. You have to check.
If this episode changed how you think about a humble file format, share it with someone who's building a digital business card — or just someone who exports contacts for a living.
Thanks to our producer Hilbert Flumingtop.
This has been My Weird Prompts.
Find us at my weird prompts dot com. We'll be back soon.
