Contacts live everywhere and nowhere. Your phone holds some, your email program holds others, an old export holds a third set, and no single list is complete. Sooner or later you need to combine them, or to divide one large list into smaller ones, for a new phone, a team, or a cleanup. The format that carries contacts between these systems is usually VCF, short for vCard, a plain-text format where each contact is a block beginning with BEGIN:VCARD and ending with END:VCARD, with lines inside for names, phone numbers, email addresses, and other details. It is a simple format, and like all simple formats, it rewards care and punishes haste: a merge done badly duplicates half your contacts, and a split done badly drops the ones that matter.

The risks are specific. Merging two files that overlap produces duplicates, sometimes exact and sometimes near, where the same person appears with a different phone format or an extra email. Merging files with different versions of the format can lose fields that one version supports and the other does not, such as photos or custom labels. Splitting a file by count alone can separate a contact's details if a contact block is cut in the middle, and splitting by group without checking group membership can leave contacts unassigned or assigned twice. The VCF Merge and Split Tool handles the combining and dividing while keeping each contact block intact, so the operations are structural, not textual guesswork.

How the tool works

Merging reads each input file, parses it into individual contact blocks, and writes all blocks into one output file, optionally removing duplicates. The parsing step is what separates a proper merge from concatenating files with a text editor: a parser understands where each contact begins and ends, handles line folding, where long lines are wrapped across several physical lines, and preserves multi-valued fields, such as a contact with two phone numbers or three email addresses, as parts of one contact rather than as separate entries. Deduplication, when requested, compares contacts on a chosen key, usually name plus a phone number or email address, and keeps one copy, following the same judgement as any duplicate cleanup: exact matches are safe to remove, near matches need review.

Splitting works in the opposite direction. The tool reads one file's contact blocks and writes them into several output files, by count, by group, or by a filter such as a category or organisation. Splitting by count is the simplest: the first N contacts go to the first file, the next N to the second, and so on, with every block kept whole. Splitting by group uses a field inside the contacts, such as a category label, to route each contact to the file for its group, and contacts without a matching group need a defined destination, or they will be lost. In both modes the output files are valid VCF files in their own right, each with complete contact blocks, ready to import anywhere that accepts VCF.

Version handling matters in both directions. The common vCard versions are 2.1, 3.0, and 4.0, and they differ in details: how parameters are written, which properties exist, and how certain values are encoded. A merge of files in different versions can produce a mixed-version output that some importers handle gracefully and others do not. Converting to a single version for the merged output, or at least knowing which versions went in, avoids the situation where a contact imports fine into one program and loses its photo or its custom fields in another. For the neighbouring conversions, the iCloud Contacts VCF to CSV Converter turns VCF contacts into a spreadsheet, and the CSV to iCloud Contacts VCF Converter goes the other way, which is useful when the cleanup is easier in a table than in contact blocks.

A worked example

Consider a clearly-labelled sample task: you have two VCF files, one exported from an old phone with 300 contacts and one from an email program with 250 contacts, and you believe about 200 people appear in both. Merging without deduplication gives 550 contact blocks, of which about 200 are duplicates, so the merged address book shows many people twice. Merging with deduplication on name plus email gives roughly 350 contacts: 300 plus 250 minus 200 overlaps. That arithmetic is the expectation to check against the actual result. If the merged file holds 540 contacts, deduplication missed most overlaps, probably because the key was too strict, such as requiring an exact name match where one file uses "Jon Smith" and the other "John Smith". If it holds 310, deduplication was too aggressive, probably because the key was too loose, such as matching on surname alone, and distinct people were merged.

A second worked example covers splitting. Suppose the merged file of 350 contacts must be divided for three teams, using a category field: sales, support, and everyone else. The tool routes 120 contacts to the sales file, 90 to support, and 140 to the general file, and the three outputs sum to 350. That sum is the verification: if the outputs sum to fewer than the input, contacts were lost, most likely ones with no category or with a category spelling that did not match, such as "Sales" versus "sales". If they sum to more, contacts were assigned twice, most likely ones carrying two categories. Checking the sum, and listing the unassigned contacts before finalising, turns a split from a hope into an auditable operation. And in both examples, the golden rule holds: work on copies, keep the original files untouched until the merged or split result has been imported and verified in its destination, and count before and after.

Common mistakes

The most common mistake is merging without deduplication and then cleaning duplicates in the destination program, where they are harder to find and where a mistaken deletion is harder to undo. Deduplicate at merge time, on a stated key, and review near matches.

A second mistake is splitting by cutting the file as text. A contact block cut in the middle produces a corrupt file that may import partially, silently dropping the damaged contact and everything after it. Always split by contact block, never by line count alone.

A third mistake is ignoring versions. Mixed-version merges import unpredictably, so check the versions going in and aim for a single version coming out, testing the result in the actual destination program before deleting the originals.

A fourth mistake is deleting the source files immediately after merging or splitting. Keep them until the result has been imported, counted, and spot-checked in its new home, because recovery after deletion depends on backups that may not exist.

Honest limitations

A merge and split tool moves contact blocks between files; it cannot judge whether two similar contacts are the same person, repair incorrect details inside a contact, or recover fields that a source program failed to export. Near-duplicates remain a human judgement, and a merge key that is too loose will combine distinct people just as surely as a key that is too strict will miss true duplicates. The tool also cannot guarantee that every destination program imports every vCard property identically: photos, custom labels, and newer properties may be dropped by some importers regardless of how correct the file is. Finally, the tool works on the files you give it; contacts that were never exported, or that live only in a program with no export, are outside its reach.

Closing

Merge by parsing, not by pasting, deduplicate on a stated key, split by whole contacts, and verify by counting: inputs plus overlaps should equal outputs, and split outputs should sum to the input. The VCF Merge and Split Tool handles the structure, with the iCloud Contacts VCF to CSV Converter and the CSV to iCloud Contacts VCF Converter covering the spreadsheet round trip. For the companion skill of viewing VCF contacts in a table before deciding what to merge, How to View iCloud Contacts Files in a Table shows the inspection step. Contacts are relationships, not rows, so count them carefully and keep the originals until the new home checks out.