To convert vCard 2.1 to 3.0, change VERSION:2.1 to VERSION:3.0, convert bare type parameters (TEL;HOME:) to TYPE= syntax then remove the CHARSET and ENCODING=QUOTED-PRINTABLE parameters while decoding the quoted-printable text into plain UTF-8. The encoding step is the one most people get wrong. vCard 4.0 (RFC 6350) goes further and removes the ENCODING and CHARSET parameters entirely, so quoted-printable is not allowed at all in a 4.0 file. vCard 3.0 is the safest target for most platforms. The Univik vCard Converter handles the version change and the encoding decode in one step so the output is conformant.
Which vCard Version Do You Need?
Before converting, pick the right target version. The version you choose determines the encoding rules you have to follow, which is where most conversions go wrong.
vCard 3.0 is the safest default. It works with the widest range of platforms: iCloud, Google Contacts, Outlook, Thunderbird, Android, iPhone and most CRM systems. It supports UTF-8 for international characters and uses clean TYPE= syntax. If you are unsure which version to target, choose 3.0.
Use vCard 2.1 only for legacy systems, older Android devices from before 2015 or industrial and embedded hardware that requires it.
Use vCard 4.0 when your target platform specifically requires it, such as some CardDAV servers and modern CRM APIs. You also need it for properties like KIND, GENDER or MEMBER that only exist in 4.0. Just be aware that 4.0 has the strictest encoding rules, covered next.
If you are unsure whether VCF and vCard are even the same format, our VCF to vCard guide explains the naming difference.
Does vCard 4.0 Allow Quoted-Printable?
No. vCard 4.0 does not allow the ENCODING=QUOTED-PRINTABLE parameter, and this is the single most common reason a version conversion produces a broken file. RFC 6350, which defines vCard 4.0, removed both the ENCODING and CHARSET parameters. vCard 4.0 uses UTF-8 as the only permitted character set, so non-ASCII text is written as plain UTF-8 with no encoding wrapper.
This trips up a lot of people during conversion, because quoted-printable was extremely common in vCard 2.1 and many older export tools still emit it. When a tool writes a VERSION:4.0 line while keeping 2.1-style encoding, the result is a malformed file that declares one version but uses another version’s syntax. Strict parsers reject it.
Here is the encoding rule for each version, which is exactly what your conversion has to enforce:
vCard 2.1: Quoted-printable is allowed and was the standard way to encode non-ASCII text, written as ENCODING=QUOTED-PRINTABLE alongside a CHARSET parameter.
vCard 3.0 (RFC 2426): The text model moved to plain UTF-8. Quoted-printable for text is not part of the 3.0 representation. Binary data uses ENCODING=b (Base64).
vCard 4.0 (RFC 6350): The ENCODING and CHARSET parameters are both removed. Text is plain UTF-8. Binary data is referenced through a data URI. There is no quoted-printable.
The practical takeaway: when you convert up to 3.0 or 4.0, you cannot just delete the encoding parameter, you have to decode the quoted-printable text into UTF-8 at the same time. The conversion steps below show exactly how, and the vCard Converter does it automatically.
What RFC 6350 Removed: ENCODING and CHARSET
RFC 6350 was published in August 2011 and defines vCard 4.0. It obsoletes the earlier vCard specifications: RFC 2425, RFC 2426 (vCard 3.0) and RFC 4770. Appendix A of RFC 6350 lists the changes from 3.0 to 4.0, and two of them matter most for conversion.
The CHARSET parameter was removed. RFC 6350 states that UTF-8 is the only possible character set in vCard 4.0. Because there is only one allowed character set, a per-property CHARSET parameter serves no purpose. Declaring CHARSET=UTF-8 or any charset on a property in a 4.0 file is invalid.
The ENCODING parameter was removed for text. vCard 2.1 used ENCODING=QUOTED-PRINTABLE to represent non-ASCII characters as =XX hexadecimal sequences. vCard 4.0 has no equivalent. The only escaping in 4.0 text values is backslash escaping for commas, semicolons, backslashes and newlines.
Appendix A is an incomplete list
RFC 6350 Appendix A summarises the changes from vCard 3.0 to 4.0, but it is openly acknowledged to be incomplete. The CalConnect VCARD technical committee, which developed the specification, maintains supplementary documentation explaining each change. If you are implementing a parser, read the property and parameter definitions in the body of the RFC rather than relying on Appendix A alone.
For binary data such as photos, vCard 4.0 uses a data URI instead of an encoding parameter: PHOTO;MEDIATYPE=image/jpeg:data:image/jpeg;base64,[data] rather than the 3.0 form PHOTO;ENCODING=b;TYPE=JPEG:[data].
vCard Encoding by Version: 2.1 vs 3.0 vs 4.0
This table is the fastest way to see what your conversion has to change for encoding.
| Encoding aspect | vCard 2.1 | vCard 3.0 (RFC 2426) | vCard 4.0 (RFC 6350) |
|---|---|---|---|
| Character set | Per-property CHARSET= |
UTF-8 (assumed) | UTF-8 only (mandatory) |
| CHARSET parameter | Allowed and common | Not used per property | Removed (invalid) |
| Non-ASCII text | ENCODING=QUOTED-PRINTABLE |
Plain UTF-8 | Plain UTF-8 |
| ENCODING parameter (text) | Quoted-printable | Not used for text | Removed (invalid) |
| Binary data (photos) | ENCODING=BASE64 |
ENCODING=b |
Data URI (MEDIATYPE=) |
| Defining RFC | vCard 2.1 (1996) | RFC 2425 and RFC 2426 | RFC 6350 (2011) |
Quoted-printable existed to move non-ASCII characters through 7-bit ASCII systems, a real constraint when vCard 2.1 was designed in the 1990s. By 2011 that constraint was gone, so RFC 6350 dropped it. This is why a clean conversion has to decode the old encoding rather than carry it forward.
Convert vCard 2.1 to 3.0
This is the most common conversion. Samsung phones and older Android devices export vCard 2.1, but iCloud and Google Contacts work best with 3.0. If iCloud is rejecting your file, see our unable to import vCard guide. Here is exactly what changes.
Change the VERSION line. Find VERSION:2.1 and replace with VERSION:3.0. This must be done for every contact, since each BEGIN:VCARD block has its own VERSION line.
Convert type parameters to TYPE= syntax. In 2.1, types are bare: TEL;HOME;VOICE:. In 3.0 they use explicit TYPE=: TEL;TYPE=HOME,VOICE:. Apply this to TEL, EMAIL, ADR and any other property with type parameters.
Remove per-property encoding and decode the text. Delete ;CHARSET=UTF-8 and ;ENCODING=QUOTED-PRINTABLE from property lines. Decode any quoted-printable text (=C3=A9 becomes é) into plain UTF-8. Deleting the parameter without decoding the text is the most common conversion mistake.
Update photo encoding. Change PHOTO;ENCODING=BASE64;JPEG: to PHOTO;ENCODING=b;TYPE=JPEG:. The actual Base64 image data stays the same.
Command-line shortcut (Linux and Mac): For a file with ASCII-only contacts (no quoted-printable text), use sed:
This handles the VERSION and photo encoding changes but does not convert bare type parameters or decode quoted-printable text. For files with non-Latin characters, the manual route risks corrupting the encoding, so a dedicated converter is safer (see below).
Convert vCard 3.0 to 4.0
Less common, but needed for CardDAV servers and modern CRM APIs that require the latest specification. This is where the encoding rules matter most, because 4.0 removes the parameters that 3.0 still tolerated.
Change VERSION:3.0 to VERSION:4.0.
Remove any CHARSET and ENCODING parameters. vCard 4.0 does not allow them. If any property still carries CHARSET= or ENCODING=QUOTED-PRINTABLE from an earlier conversion, strip the parameter and ensure the value is plain UTF-8.
Convert TEL to URI format. In 3.0: TEL;TYPE=HOME:+1234567890. In 4.0: TEL;TYPE=home;VALUE=uri:tel:+1234567890. Type values become lowercase in 4.0.
Simplify EMAIL and update PHOTO. Drop the redundant INTERNET type from EMAIL. Change PHOTO from ENCODING=b;TYPE=JPEG: to the data URI form MEDIATYPE=image/jpeg:data:image/jpeg;base64,[data].
Downgrade vCard 3.0 to 2.1
Rarely needed, but some legacy systems and older industrial scanners still require vCard 2.1. This is the one direction where you add quoted-printable back in.
Change VERSION:3.0 to VERSION:2.1.
Convert TYPE= parameters to bare parameters. Change TEL;TYPE=HOME,VOICE: back to TEL;HOME;VOICE:.
Add CHARSET and ENCODING for non-ASCII text. If any contact names contain non-Latin characters, add ;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE to those properties and encode the text as quoted-printable. This is the reverse of the upgrade step.
Change photo ENCODING=b back to ENCODING=BASE64.
Convert vCard Versions Automatically
The manual steps above work, but two parts are easy to get wrong by hand: decoding quoted-printable text correctly and applying the syntax changes to every contact in a large file. A single missed decode leaves =C3=A9 in a name. A single missed type parameter makes a strict parser reject the file.
The Univik vCard Converter converts between vCard 2.1, 3.0 and 4.0 in one step. It changes the VERSION line, rewrites the property syntax for the target version and decodes quoted-printable text into UTF-8 so the output is conformant. It processes every contact in the file at once, which matters for exports with hundreds of contacts where manual editing is impractical.
Convert vCard versions without the manual encoding work. Load your VCF file, choose the target version (2.1, 3.0 or 4.0), and the converter applies every syntax and encoding change, including quoted-printable decoding, in one pass.
Property Syntax Differences: 2.1 vs 3.0 vs 4.0
Encoding is one part of the version difference. The property syntax also changes. Here is the same contact written in each version.
| Property | vCard 2.1 | vCard 3.0 | vCard 4.0 |
|---|---|---|---|
| Version line | VERSION:2.1 |
VERSION:3.0 |
VERSION:4.0 |
| Phone (home) | TEL;HOME;VOICE:+1234 |
TEL;TYPE=HOME,VOICE:+1234 |
TEL;TYPE=home;VALUE=uri:tel:+1234 |
EMAIL;INTERNET:a@b.com |
EMAIL;TYPE=INTERNET:a@b.com |
EMAIL:a@b.com |
|
| Photo (embedded) | PHOTO;ENCODING=BASE64;JPEG: |
PHOTO;ENCODING=b;TYPE=JPEG: |
PHOTO;MEDIATYPE=image/jpeg:data:... |
| Non-ASCII text | ENCODING=QUOTED-PRINTABLE |
Plain UTF-8 text | Plain UTF-8 text |
| RFC standard | vCard 2.1 (1996) | RFC 2426 | RFC 6350 |
vCard 4.0 also removed several properties, including NAME, MAILER, LABEL and CLASS. It added properties like KIND, GENDER and MEMBER that do not exist in earlier versions.
Fixing Garbled Characters After Conversion
Encoding is the number one cause of garbled characters after a version conversion. The failure is almost always the same: quoted-printable text was carried from a 2.1 file into a 3.0 or 4.0 file without being decoded.
Names show =C3=A9 or =E4=B8=AD instead of letters. The file still contains quoted-printable sequences that were not decoded. You must decode the =XX bytes into UTF-8, not just delete the ENCODING parameter. See our VCF encoding UTF-8 error guide for the full decode process.
The file declares VERSION:4.0 but still has CHARSET or ENCODING parameters. Those parameters are invalid in 4.0. Strip them and confirm the text is plain UTF-8. A 4.0 file should contain no =XX sequences and no CHARSET= declarations.
The VERSION line is right but the platform still rejects the file. Changing the VERSION line alone is not enough. The property syntax and encoding must match the declared version. A file that says VERSION:3.0 but uses 2.1 syntax will be rejected by strict parsers like iCloud.
Platform Compatibility Table
| Platform | Accepts 2.1 | Accepts 3.0 | Accepts 4.0 | Exports As |
|---|---|---|---|---|
| iCloud / iPhone | Partial (often rejects) | Yes (preferred) | Yes | 3.0 |
| Google Contacts | Yes | Yes (preferred) | Yes | 3.0 |
| Samsung (One UI) | Yes | Yes | Partial | 2.1 |
| Android (stock / Pixel) | Yes | Yes | Yes | 3.0 |
| Outlook Desktop | Yes | Yes | Partial | 2.1 (per contact) |
| Thunderbird | Partial | Yes | Partial | 3.0 |
| macOS Contacts | Yes | Yes | Yes | 3.0 |
| CardDAV servers | No | Yes | Yes (preferred) | Varies |
“Partial” means the platform imports the file but may drop properties or show formatting issues. For the safest result, convert to the version marked “preferred” for your target platform before importing.
Frequently Asked Questions
How do I convert a vCard 2.1 file to 3.0?
Change VERSION:2.1 to VERSION:3.0, convert bare type parameters such as TEL;HOME: to TEL;TYPE=HOME:, remove the CHARSET and ENCODING=QUOTED-PRINTABLE parameters while decoding the quoted-printable text into UTF-8. Finally change ENCODING=BASE64 to ENCODING=b for photos. The decode step is the one most people miss. The vCard Converter does all of this in one step.
Was quoted-printable removed in vCard 4.0?
Yes. RFC 6350, which defines vCard 4.0, removed the ENCODING parameter, so ENCODING=QUOTED-PRINTABLE is not valid in a 4.0 file. vCard 4.0 uses plain UTF-8 text with no per-property encoding. Quoted-printable was a vCard 2.1 mechanism and was never part of the 3.0 or 4.0 text model.
Does RFC 6350 allow the CHARSET parameter?
No. RFC 6350 removed the CHARSET parameter. vCard 4.0 permits only UTF-8 as its character set, so a per-property charset declaration serves no purpose and is invalid. A conformant 4.0 file contains no CHARSET= parameters anywhere.
Is encoding=quoted-printable deprecated or fully removed in vCard 4.0?
Fully removed, not merely deprecated. The ENCODING parameter does not exist in the vCard 4.0 specification. A file that declares VERSION:4.0 and uses ENCODING=QUOTED-PRINTABLE is non-conformant. In vCard 2.1 the parameter was valid and common; in 4.0 it has no defined meaning.
Can I just change the VERSION line without changing anything else?
For lenient platforms like Google Contacts and Android, changing only the VERSION line may work because their parsers accept mixed syntax. Strict platforms like iCloud reject a file that declares VERSION:3.0 but uses 2.1 syntax or encoding. For reliable results, apply all the syntax and encoding changes for the target version, not just the VERSION line.
What RFC defines each vCard version?
vCard 2.1 was defined by the versit consortium in 1996 and is not an RFC. vCard 3.0 is defined by RFC 2425 and RFC 2426. vCard 4.0 is defined by RFC 6350, published in August 2011, which obsoletes RFC 2425, 2426 and 4770.
Can a single VCF file contain contacts with different versions?
Technically yes, since each BEGIN:VCARD block has its own VERSION line. In practice most platforms expect all contacts in a file to use the same version, and mixed-version files cause unpredictable import behaviour. Standardise all contacts to one version before importing.
Conclusion
Converting between vCard versions is mostly about getting two things right: the property syntax and the encoding. The syntax changes are mechanical (VERSION line, TYPE= parameters, TEL and PHOTO formats). The encoding is where conversions break, because vCard 2.1 used ENCODING=QUOTED-PRINTABLE with a CHARSET parameter, vCard 3.0 moved to plain UTF-8, and vCard 4.0 (RFC 6350) removed the ENCODING and CHARSET parameters entirely.
The most common mistake is changing the VERSION line while leaving 2.1-era encoding in place, which produces a file that declares one version but uses another’s syntax. Decode quoted-printable text into UTF-8 when upgrading, strip the CHARSET and ENCODING parameters for 4.0, and verify before importing. For files with non-Latin characters or large contact counts, the Univik vCard Converter applies the version and encoding changes together so the output is conformant the first time.