Getting a CSV out of your contacts
Most people arrive here with a spreadsheet already. If you do not have one, every major address book exports CSV: Google Contacts offers it under Export, Outlook under Import/Export, and iCloud exports vCard directly, so if that is your source you do not need this tool at all.
Whatever the source, open the file and look at the header row before converting. Column names vary enormously between services — one writes Given Name, another First Name, another fname — and knowing what your file actually calls things is what makes the mapping below take ten seconds rather than needing a second attempt.
Mapping is the whole tool
Nobody's export has the column names a converter would like. Google Contacts writes Given Name, Outlook writes First Name, a spreadsheet somebody made writes fname, and a CRM export writes something else entirely.
So the columns whose names are recognisable are matched for you and shown as dropdowns you can correct. Everything else stays unset. That is deliberate: a converter that guesses silently produces a phone full of contacts named after their email address, and you find out after importing four hundred of them rather than before.
Change any dropdown and the output updates immediately, so you can check a contact or two in the panel before downloading anything.
What it can carry
Name — as first and last, or as a single full name — plus organisation, job title, email, two phone numbers, a full postal address broken into street, city, region, postcode and country, a website and a note. A row with no name falls back to the organisation, then the email, then the phone, so a partial record still imports as something you can recognise rather than as a blank.
Rows with nothing identifiable at all are skipped, and the number skipped is reported under the output rather than passing silently.
A row turned into a card
Take a row with a first name, last name, company, email, phone and
city, mapped to those six fields. This is the exact .vcf
text it produces, verified against the converter's own code rather
than typed out by hand:
BEGIN:VCARD
VERSION:3.0
N:Lovelace;Ada;;;
FN:Ada Lovelace
ORG:Analytical Engines
EMAIL;TYPE=INTERNET:ada@example.com
TEL;TYPE=CELL:+44 20 7946 0000
ADR;TYPE=HOME:;;;London;;;
END:VCARDNotice the N line: it is family name first, then given name, then three more fields the tool leaves blank (additional names, prefix, suffix). FN is the display name shown in most contact apps. ADR has seven parts — PO box, extended address, street, city, region, postcode, country — and only city was mapped here, so the rest sit empty between the semicolons.
Escaping, and why addresses break
vCard treats commas, semicolons, backslashes and newlines as
structural characters inside a value — they normally mark where one
field ends and the next begins. A street address containing a
comma, written out unescaped, would split the address into fields
that were never meant to exist, which is the usual reason an
imported .vcf arrives as garbage.
All four characters are escaped with a backslash before that can
happen. A street value of Flat 2, 15 Oak Rd; Block B
is written into the card as:
Flat 2\, 15 Oak Rd\; Block BReading it back, the reader sees the backslash and treats the comma and semicolon after it as ordinary characters, not separators. The backslash itself is escaped first — as a doubled backslash — so a value that happens to already contain one is not misread either. Long lines are also folded at 75 characters, as the vCard specification requires, by breaking the line and starting the continuation with a space. The file is UTF-8, so accents and non-Latin scripts survive intact.
The sample data above includes a name written as
"Smith, John" in one column, quoted in the CSV because
of its comma. Mapped to first name with no last name and no other
identifying column, it becomes:
BEGIN:VCARD
VERSION:3.0
N:;Smith\, John;;;
FN:Smith\, John
EMAIL;TYPE=INTERNET:john@example.com
ADR;TYPE=HOME:;;;Leeds;;;
END:VCARDThe comma from the CSV field survives as data — escaped, not stripped — because the CSV parser and the vCard escaper are two separate steps handling two separate sets of special characters.
Getting it onto your phone
Email the file to yourself and open the attachment, or put it in a cloud drive and open it from the phone. iOS and Android both recognise the format and offer to add the contacts; Outlook, Apple Contacts, Google Contacts and Thunderbird all import it directly. There is nothing to install.
Import a small file first if you can — three or four contacts — and check one on the phone before doing the whole list. Undoing a bad contact import is far more work than checking.
Your contacts stay yours
Everything happens in your browser. The file is parsed there, the vCard is built there, and this page has no upload endpoint to send anything to. That matters more here than on most tools: a contact list is other people's personal data, not only your own, and the safest way to handle it is for it never to leave the machine.
Limits, and rows that get skipped
A dropped file is capped at ten megabytes, and the shared CSV parser stops at around two million cells — a contact export is small next to either limit. Rows with no name, no organisation, no email and no phone are skipped entirely, because a vCard with nothing to call the contact is not useful; the number skipped is reported under the output so it never happens silently.
If you only need the contact data as a spreadsheet-friendly text file rather than a phone import, the CSV to TXT and CSV to TSV converters read the same kind of CSV and use the same parser, just without the vCard step.