Merge VCF Files — Combine Multiple vCards into One

How to merge VCF files — three steps

Merging vCards is not an import. You are not adding anyone to Outlook, Google Contacts or your phone. You are concatenating address-book files so the next import happens once, against one file, instead of against a pile.

1. Choose or drop several files. The picker accepts more than one, and the box accepts a drag of a whole handful of .vcf / .vcard files. Each file is read with the browser File API and split into BEGIN:VCARD … END:VCARD blocks. The list under the box shows the file name and how many cards it contributed. Nothing is uploaded; the bytes never leave the tab.

You can come back and add more. New files append; they do not replace what you already dropped. That matters when the files are not in one folder — one from an old Android export, one emailed by a colleague, one you just saved from iCloud. Add the first two, go find the third, drop it. The running total updates. Remove a single file if you grabbed the wrong one. Start over clears the whole list.

2. Read the totals. The tool shows Total N contacts from K files, and how many of those cards match an earlier card on display name (case-insensitive), phone digits and lower-cased email. A checkbox labelled Skip duplicates (same name, phones and emails) is on by default; uncheck it if you want every card kept, copies and all. The download count on the button updates live.

3. Download the merged .vcf. The button label is the count that will actually be in the file. The download is named merged-contacts.vcf. It is a single vCard stream you can import on iPhone, Android, Google Contacts or Outlook the same way you would import any other .vcf — see the iPhone guide, the Android guide and the iCloud contacts guide if you want the tap-by-tap.

Cards in the merged file appear in the order you loaded the files, and within each file in the order they were already written. Appending a file puts its cards at the end. If you merge “old phone” then “new phone”, the older cards sit first, and skip-duplicates keeps the first copy. If you need to look at a file before you merge it, open it in the viewer first. If you need to edit names, that is a different job: convert to a spreadsheet, clean it, convert back.

Where multiple VCF files come from

People do not set out to collect a pile of vCards. The pile happens, usually across a couple of years and a couple of devices, and then one day you want a single file you can import once.

Every old phone is its own export. You leave a Nokia, a Samsung, a Pixel, an iPhone 8 in a drawer. Each one has an “export contacts” or “share contacts” action that writes a .vcf. After three upgrades you have three files, overlapping but not identical — a parent still on the old phone, a work number only on the new one. Importing them one by one into Google Contacts or iCloud is how you end up with three copies of yourself and a fourth of the dentist.

iCloud is another factory for extra files. On icloud.com you can select a handful of contacts and Export vCard. Do that twice for two groups and you have two files, not one. The macOS Contacts app does the same from a selection. There is no “export everything I selected this month as one file” button, so people end up with a desktop of Contacts.vcf, Contacts-2.vcf, Contacts-3.vcf. The iCloud contacts guide walks that export; this page is what you run afterwards if you did it more than once.

Colleagues send vCards. One person, one file. A conference week produces a dozen single-card .vcf attachments sitting in Mail. Importing each tap-by-tap on a phone is busywork, and it is how a duplicate slips in when two people forward the same card. Drop them all here, skip the one person who sent their card twice, import once.

Family backups are the last common source. A shared iPad, a parent’s Android, a partner’s Google account — each dumps a .vcf. You want one file you can keep in a password manager or on a USB stick, and one import when you set up a new phone. Merge first, import once.

The destination is almost always the same: a single import. Android’s Contacts app, Google Contacts’ Import, iCloud.com, Outlook. They all take one .vcf that contains every card back to back. They do not need a zip of files. They do not need you to tap Import seven times. If you are not sure what is inside a file, do not merge it blindly — open it in the VCF viewer, read the names, then come back.

Command-line merge (cat / copy /B) — what it gets right

If you asked an AI how to merge vCard files, there is a good chance it told you to run this:

# macOS / Linux
cat contacts-old.vcf contacts-new.vcf > merged.vcf

# Windows (Command Prompt)
copy /B contacts-old.vcf + contacts-new.vcf merged.vcf

That works. A .vcf file is not a database — it is a stream of BEGIN:VCARD … END:VCARD blocks. Sticking two streams together is a legal merge. Apple Contacts, Google Contacts and Outlook will import the result. If the files are already clean and you are sure there are no copies, the shell is enough. You do not need this page for that job.

Two things the shell will not do, and both are why people come back after trying it:

• It does not skip duplicates. cat has no idea that the same FN + TEL + EMAIL appeared in both files. Import the concatenated file and you get two of yourself, two of the dentist, two of whoever was in both exports. This page counts a card as a duplicate when its display name (case-insensitive), its phones reduced to digits and its emails lowercased all match an earlier card. The first copy is kept. That is the whole delta versus the one-liner.
• It does not check that a card is complete. If contacts-old.vcf was cut off mid-PHOTO, cat will glue the broken half onto the next file's first card. Importers then reject the whole stream, or worse, import a mangled contact. This merger only concatenates blocks that have both BEGIN and END. A card cut off at the end of a file — no END:VCARD — stays out of the download and shows up in the file list as a short card count, not as a silent poison pill (a file with no complete card at all is refused with an error instead of being listed).

What the shell and this page have in common: neither rewrites cards. cat cannot drop PHOTO because it never looks inside a card. This page keeps the same property — original blocks, original photos, original X- fields — and adds the two checks above. If you already ran the one-liner and the import looks duplicated, drop the same files here with the skip-duplicates box on, and import the new download instead of cleaning by hand.

Windows PowerShell users: Get-Content rewrites encodings and line endings. Use copy /B or this page, not Get-Content, if the cards contain photos.

Lossless by design

Most “merge VCF” tools on the web parse every card into a contact object, then write a new vCard from that object. That is convenient for the programmer and destructive for you. The parser they used almost certainly understands FN, N, TEL, EMAIL and maybe ORG. It almost certainly does not round-trip PHOTO. It drops X-ABLabel, IMPP, related names, custom Android fields, the item1.TEL groupings that iCloud writes, and anything else it did not have a column for. Mixed vCard 2.1 and 3.0 files get rewritten as one version, which can mangle quoted-printable names or TYPE parameters.

This page does not do that. Each file is split with a regular expression that finds BEGIN:VCARD … END:VCARD blocks. vCards do not nest, so that split is safe. Every block is stored as the original text. When you download, the blocks you kept are re-joined with CRLF between them, plus a trailing CRLF. Anything that sat outside a BEGIN:VCARD … END:VCARD pair in the source file — a byte-order mark, a stray comment line, a card cut off before its END — is not carried into the download. Line endings inside a card are whatever the source file used. The file is read as UTF-8 text: a UTF-8 or ASCII .vcf comes out byte for byte, while a legacy single-byte encoding such as Latin-1 would have its non-ASCII bytes turned into replacement characters. Within those limits the text inside a card — the PHOTO;ENCODING=BASE64 blob, the folded lines, the CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE names, the properties this site's own parser does not even display — leave the way they arrived.

Parsing still happens, but only to build the duplicate key; the card count is simply the number of complete BEGIN…END blocks. The parser is the same one the rest of this site uses. Its output is not fed back into a generator. If we regenerated cards, a contact with a photo would come out without one, because our generator has no PHOTO field. We do not regenerate. That is the whole trick, and it is also why a photo-heavy iPhone export survives a merge here and does not survive a parse-and-rewrite merger.

Mixed versions in one file are legal. A 2.1 feature-phone export, a 3.0 iCloud dump and a 4.0 card with tel: URIs can sit back to back. Importers read VERSION per card. We do not flatten them to 3.0. A quoted-printable María from an old Nokia stays quoted-printable; a folded PHOTO from iCloud stays folded. The merged file is a concatenation, not a translation.

That is the selling point, and it is also the implementation. If a merge tool rewrites cards, it is not lossless, no matter what the heading says. The honest trade: because we do not rewrite, we also do not “clean” anything. Odd properties stay odd. A card with a malformed property stays malformed (only a card with no END:VCARD is left out). Cleaning is a spreadsheet job — VCF to CSV, then the CSV to VCF converter if you still need a vCard — and that round-trip will drop PHOTO. Use this page when you want the original cards intact.

What counts as a duplicate — honestly

The skip-duplicates checkbox only removes a card when three things all match a card already seen, in load order:

• Display name, compared case-insensitively after trim — the same display name the rest of this site uses to label a card.
• Phone numbers, reduced to digits and sorted, so +1 (555) 010-4477 and 15550104477 count as the same number.
• Emails, lowercased and sorted.

The first copy is kept. Later cards with the same key are counted as duplicates and, with the checkbox on, left out of the download. Uncheck the box and every original block is kept, copies and all. The “N duplicates found (same name, phones and emails)” figure still tells you how many extra copies were sitting there.

That is it. We do not fuzzy-match. “J. Smith” and “John Smith” are different names. “Bob” with a mobile and “Bob” with that mobile plus a work line are different, because the sorted phone lists are not equal. A card that has no name, no phones and no emails — a photo-only remnant, a broken export — is never treated as a duplicate, because we do not have a fingerprint we trust. Deleting it would be guessing, and two photo-only cards are not “the same person”.

If you need fuzzy cleanup, this is the wrong tool. Convert the merged file (or the originals) with the VCF to CSV converter, de-duplicate in Excel or Google Sheets the way you actually recognize people, then convert the cleaned list back with the CSV to VCF converter if you still need a vCard. You will lose PHOTO on that round-trip; that is the trade, and it is why this merger exists as a separate page instead of being folded into the spreadsheet tools.

The skip is for the boring case: you exported the same Google Contacts account twice, or someone mailed you a vCard you already had from a previous dump. For that, keeping the original bytes of the first copy is the correct answer. It is not a contacts manager, it is not a fuzzy matcher, and it will not pretend otherwise.

Merge VCF files — FAQ

• How do I merge several VCF files into one?

  Drop two or more .vcf files onto the box above, or pick them with Choose .vcf files. Each file is split into original BEGIN:VCARD blocks and listed with its card count. You can add more files later — they append, they do not replace. Check the total and the duplicate count (cards matching an earlier card on name, phone digits and email), then click Download merged .vcf. The file is named merged-contacts.vcf.

• Does merging change my contacts?

  No. The download is the original card text: each BEGIN:VCARD … END:VCARD block is kept as it was and the blocks are joined with CRLF. The file is read as UTF-8 text, so a UTF-8 or ASCII .vcf comes out byte for byte. We do not rewrite FN, TEL, PHOTO or anything else. A card that went in as vCard 2.1 quoted-printable comes out as the same 2.1 quoted-printable. Text that sat outside a card in the source file is not carried over. The only optional change is leaving out a later card whose display name, phone digits and lower-cased emails all match an earlier card, and that checkbox is yours to turn off.

• Will photos in the vCards be lost?

  No. PHOTO properties stay inside the original block, including base64 bodies and folding. Tools that parse a contact and generate a new vCard usually drop PHOTO because their generator has no photo field. This merger never regenerates a card, so the photo bytes are still there.

• How are duplicates detected, and what gets missed?

  A card is skipped as a duplicate when its display name (case-insensitive), its phone numbers reduced to digits, and its emails (lowercased) all match a card already seen. The first copy is kept. “J. Smith” versus “John Smith” is not a match. A card with no name, no phones and no emails is never treated as a duplicate. For fuzzy cleanup, convert to CSV and dedupe in a spreadsheet.

• Can I mix vCard 2.1, 3.0 and 4.0 in one merged file?

  Yes. Each card carries its own VERSION line, and importers read that per card. A 2.1 feature-phone export, a 3.0 iCloud dump and a 4.0 card with tel: URIs can sit back to back. We do not flatten everything to one version.

• How do I import the merged file on iPhone, Android or Google Contacts?

  Treat merged-contacts.vcf as any other vCard. On iPhone, AirDrop it or upload it at iCloud.com — tapping a .vcf in Mail is an import, which is what you want at this point; the iPhone import guide covers the reliable paths. On Android, open the file or import it in Google Contacts; the Android import guide has the tap-by-tap. Google Contacts on the web has Import. iCloud.com accepts a vCard upload; see the iCloud contacts guide.

• How many files can I merge?

  There is no fixed file cap. The limit is what the browser can hold in memory. A dozen phone-backup .vcf files, or a hundred single-card attachments from Mail, is routine. Tens of thousands of cards in one tab may get slow; if it does, merge in two batches and merge those two results.

• Is the file uploaded to a server?

  No. Files are read with the browser File API and joined in JavaScript on your device. There is no upload endpoint. After the page has loaded you can disconnect from the network and the merger still works. The same rule applies to every tool on this site.

• Can I just concatenate VCF files with cat or copy /B?

  Yes. vCard files are a stream of BEGIN:VCARD blocks, so cat a.vcf b.vcf > merged.vcf on macOS/Linux, or copy /B a.vcf + b.vcf merged.vcf on Windows, produces a file most importers accept. Two things the shell will not do: it will not skip duplicates, and it will not refuse a file that was truncated mid-card. This page does both — duplicate skip on display name + phone digits + lower-cased emails, and it only concatenates complete BEGIN…END blocks, so photos survive.