VCF to CSV
Every contact as a row, with names and addresses split into the columns a spreadsheet actually wants — and nothing sent anywhere.
Runs in your browser0 bytes uploadedEvery contact as a row, with names and addresses split into the columns a spreadsheet actually wants — and nothing sent anywhere.
Runs in your browser0 bytes uploadedDrop a .vcf contacts file here
Nothing is uploaded. The file is read in this tab — which matters here, because it holds other people's phone numbers and home addresses.
Both routes give the same table. Pasting is quicker for one card out of an email; the file route is the one that can tell you the character encoding, because a text box has already decoded and rewritten what you paste into it.
You exported the address book off a phone and got one file with every entry crammed inside it. Nothing on a laptop wants to open that, and the obvious move is to turn it into rows. The obvious move is also where most of these converters quietly ruin the data, because a contact record is not flat and a spreadsheet cell is.
Consider a single entry with a work number, a cell number, a home fax, two email addresses and a postal address. That is nine separate pieces of information, several of them made of smaller pieces still. Flattening it is a decision — several decisions — and a converter that pretends otherwise is making them on your behalf without telling you which ones.
Hand it over above, glance at what the receipt says it found, tick the headings you want, and take the download. Nothing installs and nothing is queued. If the export came off an iPhone or an Android handset it is likely to be one large file rather than one per person, and that is the shape this page is designed around: a few hundred entries at once, not a single business card.
Before any of that happens you get told what you are actually holding — how many entries, which edition of the format they were written in, what character encoding the bytes are in, whether any of them are encoded in the old escaping scheme, and a list of exactly which fields appear and in how many entries. All of that is on screen before you choose anything, because it is what the choices depend on.
The name field holds five values: family name, given name, any middle names, an honorific prefix and a suffix such as Jr or PhD. There is a second field alongside it holding the whole thing pre-assembled for display. The postal field holds seven values, running from a post office box through the street line to the country.
So splitting a person into Last name and First name is not us taking anything apart. The pieces were already apart, and gluing them into one cell is the extra step — an extra step that then leaves you writing formulas to undo it. Here the pieces stay pieces, the two fields nobody ever fills in are left out unless your file uses them, and the assembled display version is available too if that is all you need.
There is no correct answer, only a correct answer for what you are about to do, so you choose. Grouping by kind gives you headings like Phone (cell) andPhone (work), and its virtue is that a heading means the same thing on every single row. That is the arrangement you need to sort by anything, filter anything, or feed a mail merge. Two work numbers on one entry do not collide — the second gets its own heading rather than falling off the end.
Numbering them instead preserves the order the file itself uses and guarantees no gaps, at the cost of the headings meaning different things on different rows, which is why a companion heading records what each one is. And piling everything into one cell is there for when you simply want it all visible and have no intention of calculating with it.
One small thing that sounds pedantic and is not: the labels come from your file's own vocabulary. If the export wrote CELL you get cell, not our tidier synonym. When you later line these headings up against whatever you are importing into, you need to see what the source said rather than what we thought it meant.
This is the complaint behind most searches on the subject, and it has one cause more often than all the others combined. The 1996 edition of the format — still what plenty of Android handsets and some mail clients emit — cannot put a letter like å or é directly into a line. It encodes each byte as an equals sign and two hexadecimal digits, so a Swedish surname arrives looking like =C3=96berg, and long values are continued with a trailing equals sign rather than the indentation the newer editions use.
Readers that ignore this produce nonsense from a perfectly intact file. Worse, the character set is declared per line rather than per file, so one entry can be in Latin-1 while the next is in UTF-8, and reading the whole thing with a single assumption breaks half of it. Every line is decoded using the set it declares for itself, and the receipt tells you how many lines needed it and which sets turned up. If the damage predates you — if the bytes themselves were already mangled before the file reached you — you get a sample of the breakage from your own file, showing the mangled form beside what it was meant to be.
Entries can carry a picture, stored as text right there in the file, which is how a few hundred people end up weighing more than a video clip. A picture encoded that way runs to hundreds of thousands of characters, and dropping that into a spreadsheet produces something no application will open pleasantly.
So the image never reaches a cell. A heading records that one exists and roughly how large it is, and the receipt counts them, which is usually the entire explanation you were after. Nothing is deleted from your original — it simply stays out of the table.
Going backward is a genuine need and this is not the place for it, for a reason worth being blunt about: Google Contacts does it free and does it well. Import your spreadsheet there, then export the result as a contact file. It is a product almost everybody already has an account for, and a weaker imitation of it would waste your afternoon. The direction people actually get stuck on is the one this page handles — a file off a handset that a computer refuses to make sense of.
Search for this task and Google prints a warning above the fold telling you not to hand sensitive personal information to third-party sites, immediately above a list of sites that all ask you to upload the file. The warning is correct. An address book is other people's home addresses, other people's mobile numbers, other people's birthdays — information they gave to you and not to a converter you found in a hurry.
Everything here runs inside your own browser. There is no server to send anything to, so there is no size ceiling either: a large file earns an honest warning about what it will cost your own hardware, and then it runs anyway. Open the Network panel first, hand the file over, and watch the list stay empty; the guide to checking that for yourself walks through it. When the table is ready, theCSV viewer will open the result without a spreadsheet installed, and what a CSV file is covers why the separator and the byte order mark settings above exist at all.
Drop the .vcf on the box above or paste its text, tick the fields you want as columns, and a spreadsheet-ready table appears with the download underneath it. The file is read by this tab, so there is no upload, no account, no queue and no size limit imposed by us. If the file came off a phone it is probably called contacts.vcf and holds every contact in one file, which is exactly the case this page is built for.
A .vcf is plain text, so any text editor will show you the raw fields — but that is rarely what people mean. If you want to read it, convert it to CSV here and open the result in Excel, Numbers or Google Sheets, where one contact is one row. If you want the contacts in an address book instead, double-clicking the file adds them to Contacts on a Mac or iPhone, and on Windows it opens in the People app.
That is what this page does, and the part worth knowing is that a contact file stores names in pieces. The N field holds family name, given name, middle names, prefix and suffix as five separate values, and the address field holds seven. Splitting those into real columns is the whole reason to go to CSV, and it is the step most converters skip by pasting the raw field into one cell.
Almost certainly quoted-printable. vCard 2.1, which is what older Android phones and some Outlook exports still write, encodes any non-English letter as a code like =C3=A5 and continues long lines with an equals sign. A reader that does not decode it turns every accented name into nonsense. This page decodes it, using the character set each line declares rather than one guess for the whole file, and the receipt tells you how many lines were affected.
They are counted and described, never written into a cell. A contact photo is stored as base64 text that can run to hundreds of thousands of characters, and putting that in a spreadsheet makes the spreadsheet unusable without helping anybody. The Photo column tells you the format and rough size instead, which is usually the answer to why a few hundred contacts came to eight megabytes.
No. It is read in this tab and never transmitted. Google itself puts a warning about that on the search results page for this very task, directly under a list of converters that all ask you to upload the file, and the warning is right: a .vcf holds real people's phone numbers, home addresses, birthdays and email addresses. Open your browser's Network panel before you drop the file and watch nothing go out.
Not on this site, and the honest reason is that Google Contacts already does it for free and does it well: import your CSV there, then export the result as a vCard. It is a product most people already have an account for, and building a second-rate version of it would waste your time and ours. The direction people actually get stuck on is this one, coming off a phone with a file nothing on a laptop will open.