Making phone numbers consistent across an address book

Open your address book and look at ten phone numbers. You will find some combination of 0532 123 45 67, +90 532 123 45 67, 05321234567, 532 123 4567, and at least one with a slash in it.

Every one of them works when you tap it at home. The problems start everywhere else.

Why it matters

Dialling from abroad fails. A number stored as 0532... has no country code. From another country the leading zero is meaningless and the call does not connect. Your phone cannot fix this because it does not know which country the number belongs to.

Duplicate detection breaks. +90 532 123 45 67 and 05321234567 are the same number and two different strings. Any deduplication that compares text — which is most of it — treats them as different people, which is why "merge duplicates" leaves duplicates behind.

Messaging apps miss people. WhatsApp, Signal and Telegram match by number. A malformed stored number means someone in your contacts appears as an unknown number in the app.

Exports and imports mangle them. Spreadsheets treat 05321234567 as a number, strip the leading zero, and may render long ones in scientific notation. A CSV round trip can quietly destroy an entire column.

CRM and automation matching fails for exactly the same string-comparison reason.

The format to standardise on

E.164: + then country code then the national number, no spaces, no punctuation.

+905321234567

This is the international standard, it is what every messaging platform and telephony system uses internally, and it is unambiguous from anywhere on earth.

If you find that unreadable — most people do — a compromise that keeps the important part is +90 532 123 45 67: correct country code, spaces for legibility. iOS and macOS will format numbers for display anyway, so storing them plainly costs you little.

The non-negotiable part is the country code. Everything else is presentation.

The conversion rules

Going from Turkish national format to E.164:

• 0532 123 45 67 → strip the leading 0, prefix +90 → +905321234567
• 532 123 45 67 → prefix +90
• 00 90 532... → replace the 00 international prefix with +
• Already +90... → strip spaces and punctuation only

The same shape applies to any country: the trunk prefix (0 in most of Europe, 1 in some places, nothing in others) is dropped and replaced by + and the country code.

Two cases that need human judgement:

Short numbers. Emergency services, customer service short codes, internal extensions. These have no country code and should not get one. A blanket rule will corrupt them.

Numbers from other countries. If your address book contains German, British and Turkish contacts, you cannot prefix everything with +90. Either handle them in separate passes, filtered by something that identifies the country, or accept that a pass will need review.

This is the reason a preview matters more here than in most bulk edits.

Doing it by hand, and why you will stop

macOS Contacts has no bulk edit. Changing four hundred numbers means opening four hundred cards, clicking the field, editing, and moving on. At ten seconds each that is over an hour of the most tedious work available, and the error rate climbs steadily after the first fifty.

There is no smart group trick here either — smart groups filter, they do not edit.

Before you start

Export an archive: File → Export → Contacts Archive. Phone numbers are not something you want to reconstruct from memory, and a regular-expression rule with a small mistake can affect every card at once.

What Compact Contacts does

Bulk Edit is built for exactly this. It applies text and regular-expression transformations across many cards, and — the part that matters — it previews every change before saving. You see the before and after for each affected number, which is how you catch the short codes and the foreign numbers before they are rewritten rather than afterwards.

Saved views with ALL or ANY rules let you narrow the operation first: everyone whose number starts with 0, or everyone in a particular group, so you can run a Turkish pass and a German pass separately instead of one rule that is wrong for some cards.

The dense, sortable table matters here too — sorting by the phone column makes the format inconsistency visible at a glance, which is close to impossible one card at a time.

Eligible changes can be recovered from an encrypted local history if something slips through the preview. And when you export afterwards, CSV and vCard exports are previewed before they are written, so the spreadsheet mangling in the second section is something you see coming.

Contacts and Notes are processed on your Mac. No developer contact cloud, no app account, no advertising, no third-party analytics — macOS and your account providers continue to handle synchronisation.