You export contacts and the app asks which vCard version you want. Pick wrong and the file either loses your accented names or gets rejected by the program you are importing into. Neither failure announces itself.
Short answer: choose 3.0. It is not the best format, and it is the one that works everywhere.
Which vcard version should I use, in one paragraph
Use 3.0 when you do not control what opens the file, which covers almost every real situation. Use 4.0 when you control both ends and want the cleaner format. Convert 2.1 files rather than passing them on.
That is the entire decision. The rest of this explains why, which matters when the default goes wrong.
What the rfc 6350 changes actually did
Version 4.0 arrived in 2011 and tidied up two decades of accumulated awkwardness.
UTF-8 became mandatory. Version 3.0 supported it; 4.0 requires it, and quoted-printable encoding is banned outright. That single change removes the most common source of mangled names.
A property called KIND appeared, letting a card describe an organisation, a group or a location rather than assuming every card is a person. Groups gained a MEMBER property. GENDER was added.
Some things went. NAME, MAILER, LABEL and CLASS were removed, along with inline agent cards. Almost nobody used them, which is why the removal passed quietly.
Phone numbers moved toward a URI form, and preference became a numeric ranking instead of a flag. Small changes that matter to implementers and almost nobody else.
The vcard version compatibility problem
Here is the awkward part. Version 4.0 has been standardised since 2011 and support is still uneven.
Older Outlook builds handle 4.0 badly. Several Android contact apps do too, and the failure is rarely a clear error — more often a field goes missing, or the import quietly produces fewer contacts than the file contained.
Version 3.0 has no such problem. Every address book worth naming has understood it since 2001, and nothing in common use rejects it.
So the better format is the riskier one. That is an unsatisfying answer and it is the true one.
Does Outlook support vcard 4?
Partially, and the details depend on which Outlook you mean. There are now several products under that name, and they do not behave identically.
We would not rely on it for a bulk import. If a client tells us the destination is Outlook, we export 3.0 and stop thinking about it.
The test worth running takes two minutes: export five contacts as 4.0, import them, and check that every field arrived. Do that before committing a few thousand records to a format that might drop something.
Why 2.1 files cause visible damage
Version 2.1 is from 1996 and still turns up in exports from old phones and legacy systems.
It stores non-English text using quoted-printable encoding, which later versions dropped. A modern reader that does not expect it displays the raw encoding instead of the name, so accented and non-Latin characters arrive as strings of equals signs and digits.
The damage is in the file, not the app displaying it. Converting cannot always undo it, because the reader has to guess what was intended. Re-exporting from the original device in a newer version is the only clean fix, and it is worth doing while that device still exists.
How to tell what you have
Open the file in a text editor and read the second line. It says VERSION: followed by the number.
For a file with hundreds of cards, checking by hand is a poor use of an afternoon. The vcf viewer reports the versions present in one pass and flags mixed files.
Mixed versions are normal, not a fault. It usually means the file was assembled from two exports, and every reader we have tested copes.
What the version does not change
Plenty of contact problems get blamed on the version and have nothing to do with it.
A lost country code is a data problem: something stripped the plus, usually a spreadsheet treating the number as a number. A company name cut off at a comma is an escaping problem in whatever wrote the file. A QR code that will not scan is carrying too much data, and both versions produce almost identical byte counts.
Duplicates after an import are about missing unique identifiers, not versions. Understanding how a vCard file is put together makes it much easier to tell these apart.
Our default, and when we break it
We write 3.0 unless asked otherwise. Our vcard generator defaults to it and offers 4.0 behind a dropdown for people who know why they want it.
We switch to 4.0 for two reasons only: a system that specifically requires it, or a card full of international text going somewhere we know handles it. Otherwise the older format costs nothing and removes a whole category of silent failure.
Test before you commit in bulk. Export a handful, import them, check every field arrived, and only then run the whole list. If you are pulling contacts out to inspect them properly first, the vcf to csv converter lays every field out in columns where a missing value is obvious.