Convert VCF to CSV

Nobody converts contacts to read them. The file exists because something has to move: a phone’s address book into a CRM, a departing colleague’s contacts into a shared account, a mailing list out of Outlook and into a newsletter tool, five hundred cards collected at a conference into whatever the sales team uses.

That makes the destination’s expectations the thing that matters, and destinations are opinionated. A CRM import screen wants a column called something like "Mobile Phone" and another called "Work Email", mapped one to one. A vCard has neither concept: it has a list of telephone properties with type labels attached, any number of them, in any order. The whole of this page is about that mismatch.

Every contact becomes a row of `name`, `first name`, `last name`, `organisation`, `title`, `emails`, `phones`, `addresses` and `note`. The three plural columns hold everything of that kind for the contact, separated by a semicolon and a space, with the type in front where the card supplied one: `cell: +49 30 1234567; work: +49 30 7654321`.

The alternative was numbered columns, and it is worse in both directions. Choose five and the contact with six numbers loses one silently. Choose the maximum found in the file and everybody else gets a row with a dozen empty columns whose meaning shifts from contact to contact, since the fourth number is a fax for one person and a home line for another. Collecting them keeps the table honest about what a vCard actually is, and moves the splitting to the point where you know what the destination wants.

Two routes, depending on how uniform the export is. If almost every contact has the same shape — one mobile, one work number — Text to Columns on the semicolon in Excel or Google Sheets does it in one step, and you then delete the type prefixes with a find-and-replace.

If the shape varies, Power Query is the tool: Split Column by Delimiter into rows gives you one row per number, which you can then pivot on the type prefix into properly named columns and merge back. It is ten minutes and it survives the next export, which matters because this is rarely a one-off job. Whichever route you take, do the splitting in the spreadsheet rather than asking the CRM to interpret a compound cell — most will accept it, store it whole, and produce an address book where nobody’s number is dialable.

A vCard address is a structured value with seven components in a fixed order: post office box, extended address, street, locality, region, postal code and country. Most cards leave several empty, so an ordinary German address is written with two leading semicolons and an empty box and extension.

Those empty components are dropped and what remains is joined with commas, which gives a readable `Hauptstraße 3, Berlin, 10115, Germany` and destroys the structure. Nothing in the resulting cell says that `10115` was the postal code rather than a house number, and a contact with two addresses has both in the cell separated by a semicolon. For a mail-merge that prints an address block, this is exactly right. For a CRM that wants separate city and postcode fields, the column has to be reviewed by hand or re-derived from the source, and there is no rule that will do it reliably across countries.

A vCard carries the name twice: once as a formatted string for display, which becomes the `name` column, and once as a structured value in the order family, given, additional, prefix, suffix. That structured value populates `last name` and `first name`, in that order, which is the usual way to get it wrong when reading a vCard by eye.

Both are kept because they disagree more often than you would expect. Cards created by scanning a business card frequently have a formatted name and an empty structured one. Cards from an Asian-language address book may have the structured field filled and a formatted name in a different order. Sorting on `last name` is right when it is populated; falling back to `name` when it is not is the safest rule, and having both columns in front of you is what makes that decision possible.

A modern vCard can carry a photograph, a birthday, several web addresses, instant-messaging handles, a geographic position, a time zone, categories, a related-contact list and any number of vendor-specific extensions with an `X-` prefix. None of them appears in the output.

The photograph is the one worth naming, because it is usually the bulk of the file — a base64-encoded image on every card is why a five-hundred-contact export is several megabytes rather than a hundred kilobytes. Nothing about a table could hold it. The others are omissions of scope rather than of possibility, and if a birthday or a website matters to the migration, the honest answer is that this conversion does not carry it and the source file still does.

Both this format and its calendar sibling wrap long values at seventy-five octets and mark the continuation with a leading space or tab. Those are rejoined before anything is parsed, which is what stops every long note and every long address being silently truncated at the wrap point.

What is not handled is quoted-printable, the encoding vCard 2.1 used for anything outside plain ASCII. Exports from older phones and some Outlook versions write `Müller` as `M=C3=BCller` and break long lines with a trailing equals sign rather than a leading space, which is a different folding rule. Those values come through as they are written. If your names are full of equals signs and hex pairs, re-export as vCard 3.0 or 4.0 from the source if you can, and decode the file first if you cannot.

The label in front of a phone number or an email address is the card’s own type parameter, lowercased. Where a property carries several types — a number marked as both work and voice, which is common — only the first is used, so `TYPE="WORK,VOICE"` becomes `work`.

That is usually the informative half, since `voice` distinguishes a phone from a fax and everybody has phones. It does mean the labels are as consistent as the source, which is to say not very: one export writes `cell`, another `mobile`, a third `iphone`, and a card created by a web form may carry no type at all and produce a bare number with no prefix. Normalising those into whatever your destination expects is a find-and-replace worth doing once on the whole column.

A contact export from a phone that has been synchronised with two accounts routinely contains the same person twice, and the CSV reproduces that faithfully. There is no identifier column to deduplicate on — the vCard identifier property is not among the nine, and in practice it is unstable across systems anyway.

So deduplication is a matching problem. Email address is the strongest key when it is present, followed by the formatted name plus the organisation. Do it in the spreadsheet before the import rather than after: most CRMs have their own merge tooling and all of it is slower and more consequential than sorting a column and deleting rows. Sorting by the emails column and scanning for repeats takes a couple of minutes on a few hundred contacts.

The conversion is plain JavaScript in this browser tab. No engine is downloaded, nothing is uploaded, there is no account and no daily allowance, and the network tab during a conversion is how to confirm that rather than this sentence.

For this file type that is not a nicety. An address book is other people’s personal data — names, private numbers, home addresses — held by you and belonging to them, and uploading one to a converter is a transfer to a third party that most organisations would have to record and most individuals would not want. There is nothing here to record. Note also that this direction is one-way by design: writing a CSV back into vCards would mean guessing which column is a mobile and which is a home number, and a contacts file that imports looking correct while being subtly wrong is worse than no file at all.