Correct Phone Number Format: Simple Tips to Master

If you’ve read my article on customising address fields, you already know I care (too much?) about consistency and standards. That same itch now pushes me to chase the correct phone number format. Friends once joked I must be on the spectrum¹. I laughed along; computers share that trait, and that’s why we get on so well.

Most people treat phone–number formatting as an afterthought. Hand it to a solutions architect, though, and that tiny detail turns mission–critical. I’ll bust a few myths and lay out practical rules. You’ll see how sloppy numbers can break databases, integrations, and the user experience.

Phone–number Standards: E.164 and E.123

Phone–number guidelines don’t come from guesswork. The International Telecommunication Union (ITU) sets two key standards:

E.164 defines the global numbering plan for the public switched telephone network (PSTN).
E.123 explains the international notation of phone numbers (how to write numbers for humans).

Understanding the Phone Numbering Scheme

So how does the PSTN know where to route a call? When we dial, we combine the subscriber number with trunk prefixes—extra digits that tell the network how far the call must travel. The number itself never changes, but the prefixes vary by country, region, and even carrier. Examples of trunk prefixes include:

International call prefix: Also called an exit code. It tells the network you are calling another country or region. For example, dialling Brazil from the UK starts with 00 as the international call prefix, followed by 55 which is Brazil’s country code. From the USA you start with 011 instead of 00.
Long distance call prefix: Signals that the call leaves the local area. For example, calling Birmingham from somewhere else other than Birmingham (e.g., London) starts with 0 as the call prefix, followed by Birmingham’s area code 121.
Operator prefix: Some countries make you pick a carrier. In Brazil, you insert a two–digit operator code between the trunk prefix and the number. You add it for every international or long–distance call.

Besides these prefixes, we have the actual phone number, also known as subscriber number. Now that we understand the phone–numbering scheme, we can look at the main issues with telephone–number formatting.

First issue: Writing Down the International Call Prefix With a Phone Number

When people write phone numbers, many add the international prefix (e.g., 00) before the country code. That habit is wrong. The digits 00 are not part of the number. They form a trunk code some countries use to tell the network the call is international. Different nations use different international trunk codes—for example, the USA and Canada use 011. So to someone in the USA or Canada (or Japan, Israel, Australia…) seeing 00 before a number makes no sense.

Because trunk codes vary, E.123 recommends using a ‘+’ (plus sign) instead. Most network operators and computer systems read the plus sign. They swap it for the correct exit code on the current network. The rule matters even more when you roam across countries that use different codes. Always save contacts with the plus sign in mobile phones.

Second issue: Confusing Trunk Prefixes and Area Code

This is by far the biggest sin in phone–number formatting. To understand it, we must explore a few parts of each numbering plan.

Area codes differ by country and can be fixed or variable in length. For example:

Fixed–length area code: In Brazil, every area code has two digits: 21 for Rio de Janeiro, 11 for São Paulo, etc.
Variable–length area code: In the United Kingdom area codes run two to five digits: 20 for London, 121 for Birmingham, etc.

Notice the missing leading 0 in those examples. In Brazil and in the UK, the leading 0 is a long distance call prefix which one would dial only if the number they are trying to reach is outside their area. Moreover, when calling Rio or Birmingham from abroad (say, from New York), one would drop the 0 between the country code and the area code. This is because both nations use variable–length dialling plans instead of fixed ones.

NOTE: Fixed–length and variable–length area codes should not be confused with dialling plans, which are explained below.

Variable–length Dialling

Some countries use separate dialling rules for local and long–distance calls. You add or drop trunk prefixes based on where the call starts. In both Brazil and the UK a local call within the same city needs no area code. You dial only the subscriber number. A call from outside the area, however, must include the area code.

For example, to reach Birmingham City Council:

From Birmingham: 303 6789 — dial the number only.
From elsewhere in the UK: 0 121 303 6789 — add the long–distance prefix 0, then Birmingham’s 121 area code, then the subscriber number.
From France: 00 44 121 303 6789 — dial the international call prefix 00, the UK country code 44, then Birmingham’s area code 121, followed by the subscriber number. Notice the 0 between the country code and area code is omitted.

Misusing Parentheses in Variable–length Dialling

ITU–T Recommendation E.123 says to put the area code in parentheses. The brackets show digits you may drop when calling locally. Following that rule, Birmingham City Council’s number becomes:

+44 (121) 303 6789

Many people instead write:

+44 (0) 121 XXX XXX or +44 (0121) XXX XXX

Those versions are wrong. The 0 before 121 is only a long–distance prefix; 121 is the area code. A common misconception says parentheses mark trunk digits. This causes confusion to the point some people would not know when to include the prefix or the area code, resulting in calls failing or routing incorrectly.

The confusion is widespread in the UK. Even the current Wikipedia article on UK dialling treats the long–distance prefix as part of the area code. It lists London’s code as 020, but 0 is the prefix and 20 is the code. The correct format for a Greater London phone number is +44 (20) 8XXX XXXX, not +44 (020) 8XXX XXXX.

Full–number (Closed) Dialling Plan

In a full–number (closed) plan, callers always dial trunk prefix and area code, even on local calls. Many closed plans also fix the total length of every national number, though that rule is separate.

Paris Example

In France the area code for Paris is 1. If someone would like to call the Paris City Hall (Hôtel de Ville):

From Paris: 0 1 4276 4040 — the leading 0 is mandatory.
From elsewhere in France: 0 1 4276 4040 — same as above.
From the UK: 00 33 1 4276 4040 — 00 (international prefix), 33 (France), 1 (Paris), subscriber number. Notice the 0 after 33 is omitted.

Rome Example

Italy goes further: it abolished long–distance prefixes by folding the 0 into the area code. Rome’s area code is 06. If someone would like to call the City of Rome information hotline:

From Rome: 06 0606 — 0 is part of the area code.
From elsewhere in Italy: 06 0606 — same as above.
From the UK: 00 39 06 0606 — 00 (international), 39 (Italy), 06 (Rome), subscriber number.

Practical Implications

To be clear, I don’t expect anyone to memorise phone–number quirks; it’s a niche topic. Trouble starts when we treat our local dialling habits as universal rules. Build that assumption into software and it soon breaks. In data design, personal opinion is irrelevant—only what a computer can parse without guesswork matters.

Years ago, I travelled abroad with my father and watched him wrestle with his BlackBerry. He tried to call a saved number back home, but the call failed. The contact stored the number as if he were in Rio, complete with the long–distance prefix and an operator code. I ended up editing his address book to follow the correct phone–number format.

The Correct Phone Format

Which format is the correct phone number format? The one spelled out in ITU–T Recommendation E.123. It works from any country:

+[COUNTRY CODE] [AREA CODE] [PHONE NUMBER]

Here are some examples:

Birmingham City Council: +44 121 3036789
Paris City Hall: +33 1 42764040
City of Rome Information Hotline: +39 06 0606

I store every contact this way—in systems I build and on my phone. I have never had a failed call. Local and long–distance calls simply ignore the extra digits.

On mobile phones, the dialler converts + to the correct exit code and ignores spaces, dashes, and parentheses before placing the call. When an operator prefix is required, the carrier’s switch inserts its own code by default (at least in Brazil) if one wasn’t provided.

Dialling Assistants: Do Not Take Them for Granted

Modern iPhones, Pixels, and many flagship Androids ship with a dial assist feature that quietly rewrites numbers on the handset. That convenience fixes common mistakes—but it can also cement bad habits.

Suppose you saved Birmingham City Council as 0044 121 303 6789. While roaming in the USA, most recent phones on major carriers still complete the call. The dialler converts 00 to +, swaps in the exit code 011, and strips stray trunk digits.

The correction happens in the phone’s OS through large rule tables, but many carriers also tolerate extra or alternative prefixes, giving the call a second chance. Those tables cost money to maintain and sometimes lag behind numbering–plan changes (also, I could write an entire post about the confusion Ireland caused with the 1 and 1800 area codes). If you’re building software, never assume dial assist will rescue a badly formatted number.

Storing and Presenting Phone Numbers

Now that we’ve reviewed proper formatting, we need to decide how to store phone numbers. Data should stay neutral; presentation can add local flavour. I therefore store numbers as bare digits: country code, area code, subscriber number. I add no plus sign, dashes, or parentheses.

Why Keep Them Raw?

A clean numeric string lets the application format the number any way it needs. A script can prepend +, or the application logic could determine the user’s location and show 00 for UK users, 011 for US users, and so on. Same goes for long distance prefixes.

One Field orMmany?

Should you keep the phone number in one field, or split it into country, area, and subscriber parts? Decide based on what the system will do with the data. If the number only supports dialling or messaging, a single field is simpler. If routing or reporting depends on parts of the number, splitting helps. Although, how suitable would it be to perform analysis based on fields related to phone numbers?

Beware Analytics by Phone Number

Unless you have a specific requirement for analysing patterns in phone numbers, it is likely that you might obtain answers to your data looking elsewhere. Grouping customers by country is easier with the address’s country field. Countries can share the same dialling code (e.g., NANP members), so the phone number alone can mislead. When you really need such analysis, extract data into a mart or cube and parse the components there.

Normalised or Denormalised Tables?

If you choose multiple fields, decide whether to normalise them. Separate lookup tables add integrity but also complexity:

Some countries share the same dialling code (USA, Canada, etc.), so you need the area–code combo to identify the nation.
In Italy the leading zero is part of the area code, not a trunk prefix.
Subscriber and area–code lengths can vary—even within one country (e.g., Finland).

Bottom line, it would be fairly complex to design a regular expression to validate phone numbers for each country/region. Validation becomes a forest of edge cases, so weigh that cost first.

Three Ways to Validate Input

When allowing users to input phone numbers, we have three options:

Real–time validation in the client. Block non–digits, auto–insert spaces, show red/green status icons, and explain errors.
Post–process in the app layer. Let users type freely and normalise the number before saving.
Cleanse later. Accept whatever the user enters and run a batch cleansing job (e.g., SQL Data Quality Services).

I find a blend of options 1 and 2 works best: correct obvious issues up front, then normalise on save. Keep option 3 for imports or system integrations.

Presenting the Number

Once the application retrieves the stored number, it can format it to match the audience’s convention. Add support for new formats only when there is a clear need.

Conclusion

Phone numbers follow a complex pattern that varies from region to region. Not only the lengths of phone numbers, but also the prefixes used and the convention used to display phone numbers. Remember mobile phones and other phone systems have complex dialling assistants coded into them which corrects the majority of mistakes. So unless you have a dialling assistant in place you should not expect phone numbers to magically work if they are saved incorrectly. Also, it is important to separate the concept of storing data from presenting data. It is best to follow neutral convention for storing phone numbers that makes it easier to apply any convention afterwards at the application or client layer.

Turns out they were onto something! ↩︎