The sad story of the vCard format and its lack of interoperability

I have tried to reach the zen of address book synchronisation for many years. However, I have always experienced that some contact information, especially instant messaging and social networking addresses, gets lost or corrupted during the synchronisation.

The most adopted format for representing contact information is the vCard, whose last version is the 4.0 (see IETF’s RFC 6350, 2011), while the most adopted protocol for accessing contact information is the CardDAV (see in the IETF’s RFC 6352, 2011), which is based on the vCard format. Therefore, I performed a little empirical study of the actual interoperability of the vCard format.

First, I defined a sample contact:

Joe Bloggs
+44 20 1234 5678
1 Trafalgar Square, WC2N London, United Kingdom
Skype: joe.bloggs
Twitter: @joebloggs

Second, I added this contact to four different address books:

  • Apple Contacts (formerly Address Book)
  • Cobook
  • Google Contacts
  • Memotoo

Third, I exported each of the address books to a vCard file.

Fourth, I created a sample vCard file based on the vCard format 4.0.

Finally, I compared the exported vCard files and the sample vCard file among each other. The differences between these files blew my mind.

In the following, I show these vCard files and discuss the properties that are not interoperable. Note that I stripped the irrelevant properties and rearranged the remaining properties to make the comparison easier.

Sample vCard file

FN:Joe Bloggs
TEL;TYPE="cell,home";PREF=1:tel:+44 20 1234 5678
ADR;TYPE=home;PREF=1:;;1 Trafalgar Square;London;;WC2N;United Kingdom

In my opinion, the specification of the vCard is substandard. Believe or not, it does not support social networking addresses yet. Even worse, it supports constructs that prevent interoperability, namely grouped properties and non-standard properties.

Grouped properties are properties prefaced with the same group name. They should be grouped together when displayed by an application. I will show examples of grouped properties later.

Non-standard properties are properties defined unilaterally or bilaterally outside the standard. They may be ignored by an application.

For instance, I was forced to represent the Twitter address by a non-standard X-SOCIALPROFILE property:


Apple Contacts (version 7.1)

FN:Joe Bloggs
TEL;type=CELL;type=VOICE;type=pref:+44 20 1234 5678
ADR;type=HOME;type=pref:;;1 Trafalgar Square;London;;WC2N;United Kingdom

The vCard file exported by Apple Contacts is only partially based on the vCard format 3.0 (see IETF’s RFC 2425 and RFC 2426, 1998) and its extension for instant messaging (see IETF’s RFC 4770, 2007).

The web address is represented by a standard URL property grouped together with a non-standard X-ABLabel property:


This issue can be solved by changing the type of the web address from “home page” to “home”. This leads to a vCard file where the web address is represented by a standard URL property:


The Twitter address is represented by a non-standard X-SOCIALPROFILE property:


Cobook (version 1.1.6)

FN:Joe Bloggs
item2.TEL;type=VOICE:+44 20 1234 5678
item3.ADR:;;1 Trafalgar Square;London;;WC2N;United Kingdom

The vCard file exported by Cobook is only partially based on the vCard format 3.0. With the exception of the name, all the contact information is represented by either grouped properties or non-standard properties.

Google Contacts (15 November 2012)

FN:Joe Bloggs
TEL;TYPE=CELL:+44 20 1234 5678
ADR;TYPE=HOME:;;1 Trafalgar Square;London;;WC2N;United Kingdom

Google Contacts does not support social networking addresses natively, so I was forced to add them as URLs.

The vCard file exported by Google Contacts is only partially based on the vCard format 3.0 (see IETF’s RFC 2425 and RFC 2426, 1998).

The colon in all the URLs is unnecessarily escaped.

Similar to Apple Contacts, the web address is represented by a standard URL property grouped together with a non-standard X-ABLabel property:


I guess this is because Google Contacts specifically targets Apple Contacts when exporting to a vCard file. This issue can be solved by changing the type of the web address from “Home Page” to “Home”. This leads to a vCard file where the web address is represented by a standard URL property:


The Skype address is represented by a non-standard X-SKYPE property:


The Twitter address is represented by a standard URL property grouped together with a non-standard X-ABLabel property:


Memotoo (15 November 2012)

FN:Joe Bloggs
TEL;HOME;CELL:+44 20 1234 5678
ADR;HOME:;;1 Trafalgar Square;London;;WC2N;United Kingdom

The vCard file exported by Memotoo is only partially based on the vCard format 2.1.

The Skype address is represented by a non-standard X-SKYPE-USERNAME property:


The Twitter address is represented by a non-standard X-TWITTER property:



Given the results of this study, it is not surprising that the import/export of vCard files as well as the synchronisation via CardDAV do not behave as expected most of the time.

Common contact information such as email addresses, telephone numbers, postal addresses, web addresses, and instant messaging addresses can be represented in two ways: using standard properties, or using standard properties grouped together with non-standard properties. The second way is currently used by Apple (and other vendors targeting Apple); it is unnecessary, prevents interoperability, and promotes vendor lock-in.

Other common contact information such as social networking addresses are not supported at all.

So what should be done? Here is my suggestion:

First, the IETF should remove grouped properties and non-standard properties from the specification, since open standards should promote rather than prevent interoperability. Second, the IETF should add social networking properties to the specification. Third, the IETF should provide an official validator for vCard files. Finally, the vendors should implement the last version of the vCard format, and they should do it right.

Update 22 November

I have shared my concerns in IETF’s vCardDAV mailing list. You can follow the thread here.


  1. Social networking addresses should be using the ‘URL’ according to rfc6350. eg:

  2. I run into this trying to migrate from Apple Contacts in iCloud to google contacts. Apple only exports in vCard format, and google contacts does not import photos or social media ( twitter, Facebook instagram ) data. Since I need this data of my 1000 contacts, I cannot migrate out Apple Contacts.

    • I´m keen on migration…
      If you are able to code PHP you can easily adjust a solution* we programmed to get CardDAV data to the phone book of Germanys famoust rooter (FRITZ!Box). You will probably solve your problems to migrate from Apple to Google.
      Good luck

      * carddav2fb

  3. Thanks. Your article help me solve a few headaches, explain why information was not carrying across devices, and work work towards creating a vCard that was (as much as possible) cross device compatible for our app

    Here is the format that was settled on. It seems deceptively simple looking back at it, but it’s the result of a lot of trial and error, exporting and importing to get the information across multiple devices (Tested between Google Contacts, iPhone, Android, Outlook and Apple Contacts). Treat any social media as URIs. Annotate them with itemX. Avoid any vendor X- extensions, eg X-SOCIALPROFILE, X-SKYPE, etc.

    FN:Freddie Flindstone
    NICKNAME:Freddie Flindstone
    ADR;type=WORK;type=pref:;;55 Rock Ave;Bedrock 43246
    TITLE:Dinosaur Operator
    ORG:Rubble inc
    NOTE:Wife is Wilma

  4. Well considered all around. I am researching sales support systems as part of a university project that I’m working on in the United States for graduate students.

    The lack of a standardized microformat continues to be a real problem.

    I will send you a note, I’d like to interview you.


  5. What I find particularly appalling is that Google Contacts exports vCard 3.0 files, but strips the thumbnail image data. If a vCard 3.0 file with image data is imported in Google Contacts, it ignores the image data. To recover the image, one would need to process the Base64 encoded image data separately to create a JPEG or PNG file, and then insert the image in Google Contacts manually. Yet, the Contact application in Android phones, based entirely on Google technology, can exchange contacts phone-to-phone with a Bluetooth link and preserve the image, and can export to a .vcf file and import from a .vcf file, keeping the image intact. Contacts created entirely on an Android phone or tablet with an included image preserve that image when synchronised with Google Contacts, and vice versa. Why the complete disconnect on the Google Contacts side, being unable to export complete vCard data for offline archiving and being unable to automatically recover such archived vCard data? Google has been offering its Contacts service for quite a number of years now, and still hasn’t seen fit to correct this glaring deficiency in their scheme.

  6. the beauty of URIs that they are URIs. Uniform. So we just need to use them and eventually parse them.


    So long for the X-SOCIALPROFILE extension. Damn pointless.

  7. Alessandro, i feel your frustration. And i totally agree with your third recommendation.

    We started List.Up ( with the vision of making smartphones contact list always accessible and always safe.

    vCard handling has always been our biggest frustration from day 1.

    Btw, for Apple contacts, we notice Notes are not exported in vCard. Our solution is using X-ABLabel which we know will contribute more problems into the vCard ecosystem.

  8. thanks for the information

  9. Nice article, the examples were helpful to me. Unfortunately these issues will never be resolved and synchronization will always be painful unless we want cookie-cutter apps that are all the same. Don’t get me wrong, I’d love to see one app get total domination and become a super monopoly so that we all use the same OS on our desktops, laptops, and mobile devices, and all of the same built-in apps and never have to install an app again. Everyone’s life would be so much easier, and I could give you the exact steps to “resend an email” or “copy a file” without having to ask what OS you use and what version of what app and what display settings, etc, etc. For a time I thought/hoped Microsoft would crush all others, but sadly things seem to be going the other direction with all the Mac fans, and Google’s share of the mobile market. It’s not that I like Windows/Microsoft, I just want someone to have a monopoly to make our lives easier.

  10. man, everything exports to csv… stick with csv.

    I like the gmail method… let me pick my own “label” and data, instead of just work, home, fax.

    Seriously, I don’t understand why they make an address card so complicated. A dozen or so thing that most everybody has as requirements.. name, address, main phone, phone type, email, birthday, categorie[s]… end of story.. the rest can be “extra” and just displayed like a web page +simple css(no external linking/images or scripts).

    Label, type, icon, data… let the application decide what to do, but don’t mess up and lose the user’s data and importing and exporting!!!!!!

    • I make a professional vCard converter which converts from and to CSV/vCard called OpalConvert. Having been through the nightmares that programming such an app entails, I 100% agree with you that CSV is the way to go, and that the vCard format (despite making me good money) is a load of trash not only its design, but how developers abuse the specification. To make a comparable CSV format, all we would need is a consortium to standardize the CSV fields. THAT’S IT. e.g: Stick with “First name” for the first name and “Mobile number” for a mobile number. Everyone would keep to those field names, with at most one type for each language (but I discourage that).

  11. The X-ABLabel fields are explicitly permitted in RFC 2426:

    “3.8 Extended Types
    The types defined by this document can be extended with private types
    using the non-standard, private values mechanism defined in [RFC
    2045]. Non-standard, private types with a name starting with “X-” may
    be defined bilaterally between two cooperating agents without outside
    registration or standardization.”

    I don’t understand why all products don’t simply implement this “standard extension to the standard” or why you complain that these are non-standard. The syntax is simple. Parsers for it would be child’s play. And the results would be a boon to mankind.

  12. Alessandro, first thank you for a nice wrap-up of vCard dilemma; then I point out to make matters worse, in Android Contacts, there are fields that do not get exported. So I used “Go Contacts Ex” and saw more data like network provider’s help and support fields show up. But still there are fields within the list, like Special and Other, that neither Google Contacts or “Go Contacts Ex”and few others will export. Funny that they are displayed and editable.

    I mention this to emphasis that your point in interoperability is deliberately violated, and this at the cost of not having a correct backup!

  13. I was working on a recent vCard project ( hoping to create exportable hcard widgets. The hardest part of the project was lack of interoperability, which you illustrated nicely in this article. thx

  14. Non standard properties are not for interoperability. They are so that a vendor can put their own extension into an object (vCard or iCal) and provide what they see as a value added reson to use their product. By allowing these non-standard properties and parameters into both iCal and vCard it provides a standard way to add vendor value added data that will not crash other vendors. The fact it does not crash them, is a great sign for vCard and iCal.

    -Doug Royer – rfc-4324 – that almost no one uses 🙂

    • Alessandro Rossini

      19 November 2012 at 13:42

      I understand that non-standard properties are not meant for interoperability, but I do not see why they should be included in the specification. In my opinion, open standards should first and foremost promote interoperability and prevent vendor lock-in.

      By way of an analogy, browser vendors also introduced non-standard HTML tags and CSS properties to provide what they saw as a value-added reason to use their browser. These tags and properties did not crash other browsers, but they did prevent interoperability and promote vendor lock-in, which is exactly the opposite of what open standards should aim at.

  15. Matteo Panella

    15 November 2012 at 18:27

    If you’re in for a good laugh (or facepalm, YMMV), look into iCalendar and CalDAV 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.