Why a .vcf file is so annoying to read
You exported your contacts from your phone, or someone emailed you a .vcf, and now you’re staring at a wall of BEGIN:VCARD blocks. Spreadsheets choke on it. Mail-merge tools want CSV. So do most CRMs. The vCard format is great for transferring contacts between devices, but it’s terrible the second you want to actually look at your data in rows and columns.
Paste the vCard text on the left. A CSV comes out on the right with one row per person and named columns: Full Name, First, Last, Phone, Email, Organization, Title, and URL. It re-parses as you type, so you can fix a stray line and watch the table update.
What it pulls out
Each VCARD block becomes one row. Here’s how the fields map:
- FN is the display name, dropped straight into the Full Name column. If a card has no FN, the parser builds one from the structured N field instead.
- N holds the structured name as
Last;First;Middle;Prefix;Suffix. The first two pieces fill the First and Last columns. - TEL and EMAIL can appear more than once. A contact with a cell, a work line, and a fax gets all three numbers in the Phone cell, joined with a slash. Same goes for multiple emails.
- ORG maps to Organization. If the card splits company and department (
Acme;Sales), they’re joined so nothing gets lost. - TITLE and URL round out the last two columns.
Parameters like TYPE=CELL and grouping prefixes like item1.URL get stripped, so you see the value, not the protocol noise around it.
How the conversion handles real-world mess
Exported .vcf files are rarely clean. Long lines get folded across two rows with a leading space. This unfolds them before parsing, so a wrapped email address doesn’t end up truncated. Escaped characters matter too: a comma written as \, inside a value decodes back to a real comma, and the CSV quotes that cell so your spreadsheet doesn’t split it into two columns.
The output follows proper CSV quoting rules. Any value containing a comma, a quote, or a line break gets wrapped in double quotes, and inner quotes are doubled. That means a job title like Director, Marketing stays in one cell instead of breaking your import.
When things don’t line up
Bad cards happen. Maybe an END:VCARD is missing, or a line sits outside any block, or a contact has no name at all. Instead of silently dropping rows or crashing, the tool collects these as parse notes in an amber box above the output. You still get every valid contact in the CSV, plus a short list of what looked off and which line it was on. A card opened but never closed still gets parsed, with a note so you know.
Open the result in Excel, Google Sheets, or Numbers, then re-import wherever you need it. Nothing leaves your machine, which matters when the file is your entire address book.
FAQ
Does it handle a .vcf with hundreds of contacts?
Yep. Every BEGIN:VCARD to END:VCARD block becomes its own row. One card or a thousand, same process.
What if a contact has three phone numbers?
They all land in the Phone column, separated by a slash. No number gets dropped, and multiple emails work the same way.
Are my contacts uploaded anywhere?
No. The parsing runs entirely in JavaScript in your browser. Your address book never touches a server, so it’s fine for personal or work contacts.
Can it open the .vcf file directly?
Not yet. Open the file in any text editor, copy the contents, and paste them in. The format is plain text, so this takes a few seconds.
Why is the CSV missing a name for one row?
That card probably had no FN or N field. When there’s no name, the tool falls back to the first email so the row isn’t empty, and flags it in the parse notes.
Does it keep photos or notes from the vCard?
No. Embedded photos, notes, addresses, and birthdays are skipped. The columns focus on the fields that actually map cleanly to a contact list: name, phone, email, org, title, and URL.