How to format UK mobile numbers for E.164

The E.164 form of a UK mobile number is a plus sign, the country code 44, then the ten digits that follow the leading 0. So 07700 900123 becomes +447700900123. The rule comes from two documents: ITU-T Recommendation E.164, whose current edition the ITU approved on 13 February 2026 and which caps an international number at 15 digits, and Ofcom's National Telephone Numbering Plan, which says UK numbers have "ten (10) digits (excluding the national prefix code '0')". Ten digits plus a two-digit country code makes twelve, comfortably inside the limit.

That's the whole conversion. The trouble is that real numbers turn up as 07700 900123, +44 (0)7700 900123, 447700900123, 0044 7700 900123 and 7700900123, sometimes in the same column, and a system that sends texts or matches replies has to turn all of them into one string before it can do either.

What does E.164 say about a number?

E.164 is the ITU's "international public telecommunication numbering plan". For a number tied to a country, it has three parts: a country code of "1 to 3 digits", then a national (significant) number made of a national destination code and a subscriber number. Clause 6.1 recommends that the whole thing "should be 15 (excluding the international prefix)", and clause 7.2.1 says the national part should be at most 15 minus the number of digits in the country code.

Two rules in clause 7.3 explain the conversion. First, "Prefixes are not part of the international E.164 number". Second, the national (trunk) prefix, which is the UK's leading 0, "is not included in the N(S)N" and "at the international level, the national (trunk) prefix of the country of destination must not be dialled". The same clause recommends that countries adopt a trunk prefix of "a single digit, preferably 0", and keep that digit out of the first position of the national number. In the UK that means the 0 can come off without anything being lost.

The plus sign is notation. ITU-T E.123, the companion recommendation on how numbers are written (2001, still in force), says "The international prefix symbol should be + (plus)", and that it serves "to remind the subscriber to dial the international prefix which differs from country to country". RFC 3966, the IETF's tel URI standard, puts it the same way: "a '+' symbol in E.164 indicates that an international prefix is required".

From 07 to +44, step by step

Ofcom's Plan sets aside 071 to 075 and 077 to 079 for mobile services, and fixes the length at ten digits after the 0. Turning any of the usual UK forms into E.164 takes four steps.

1. Strip everything that isn't a digit or a leading plus: spaces, dashes, dots and brackets.
2. If it starts with 00, replace the 00 with a plus. If it starts with 44 and has twelve digits, add a plus.
3. If what follows +44 starts with 0, drop that 0. This is the "+44 (0)7700" case.
4. If it starts with a single 0, drop the 0 and put +44 in front.

The third and last rows deserve suspicion. A bare 44 followed by ten digits is nearly always a UK number with the plus lost somewhere, but nearly isn't always. And ten digits starting with 7 is usually a UK mobile that a spreadsheet has stripped the 0 from (our post on cleaning a contact list covers how that happens), which you can only assume if you know the list is British.

The "(0)" form is a habit worth breaking in your own materials. E.123 says brackets mark digits that "are not always dialled", and then: "The ( ) should not be used in an international number." For printing, it adds that "Only spaces should be used in an international number", so +44 7700 900123 is the tidy way to show one.

What about Guernsey, Jersey and the Isle of Man?

The Crown Dependencies share the UK's country code, and their mobiles sit in 07 blocks inside Ofcom's Plan. Google's libphonenumber, an open source library for parsing and validating numbers, models that directly: its metadata file gives the UK (region GB) the country code 44, an international prefix of 00 and a national prefix of 0, and then lists Guernsey (GG), Jersey (JE) and the Isle of Man (IM) as separate regions with the same country code 44. Island mobiles are picked out by their blocks, for example 07781 and 07839 for Guernsey, 07797 and 07937 for Jersey, and 07624 for the Isle of Man.

That has a consequence worth testing for. If your code asks whether a number is valid for the GB region specifically, a Jersey mobile fails, because the library files it under JE. The library's own notes tell developers to take care, when calling isValidNumberForRegion, that a check against one region is what they mean. For a UK business, the check you usually want is "valid, country code 44, and one of GB, GG, JE or IM". Our post on the Ofcom numbering plan lists which operators hold which island blocks.

Validating with libphonenumber

The README describes libphonenumber as "Google's common Java, C++ and JavaScript library for parsing, formatting, and validating international phone numbers", used by Android since version 4.0. Two of its checks matter here. isPossibleNumber "quickly guesses whether a number is a possible phone number by using only the length information". isValidNumber does "full validation of a phone number for a region using length and prefix information". A third, getNumberType, tells mobile apart from fixed line, VoIP, personal numbers, pagers and the rest, which is what lets you refuse a landline before you pay to text it.

The prefix information is detailed. In the current metadata, the UK mobile pattern accepts 07700 only when the next digit is 0 or 1, which leaves out Ofcom's drama range. Ofcom keeps 07700 900000 to 07700 900999 for TV and radio, and says those numbers "cannot be allocated to communications providers for their customers" because of "the potential influx of calls" a real customer would get if a drama showed their number. That's why we use them in examples, and also why they fail validation: feed +447700900123 to isValidNumber and you get false. If your test suite uses drama numbers to check a happy path, it will fail for the right reason.

Keep the library up to date. The README says releases come out fortnightly for most of the year, and a release can consist of metadata changes alone, because numbering plans keep changing. The library's list of falsehoods about phone numbers adds that published plans "represent the intentions of the government or telecom", and a range can go live before or after the announcement says.

Taking numbers in a web form

If you collect numbers yourself, the cheapest place to fix them is the form. libphonenumber's AsYouTypeFormatter "formats phone numbers on-the-fly when users enter each digit", so the person sees their number take the familiar 07700 900123 shape as they type and spots a missing digit straight away. Allow the plus sign: the falsehoods list tells developers to "make sure you allow numbers to be entered in international format (i.e., allow the + sign)". Parse with GB as the default region, so a number typed with a leading 0 is read as British, and save the E.164 result alongside what was typed.

Two smaller things help. Say next to the field that the number is for texts, or people will give you whichever number they think of first, often a landline. And don't make the field compulsory unless you need it. The very first falsehood on Google's list is "An individual has a phone number", with the advice not to require one "unless it is essential".

How should you store a phone number?

Store the E.164 string, as text. The falsehoods list is blunt: "Never try to store phone numbers as an int or any other kind of numeric data type." A number column drops leading zeros and has no room for the plus, and a phone number is an identifier, not a quantity.

A few more rules follow from the same document and from E.164.

• Size the column for the standard with a little room. E.164 allows 15 digits, so the plus makes 16 characters, though the libphonenumber notes record German numbers longer than the ITU limit.
• Keep what the person typed until you've parsed it. The falsehoods list says that until user-supplied data has been verified as a phone number, it should be stored "as-is as entered by the user".
• Don't store whether a number is valid or what type it is. The library's advice is to "Check this information again from the library when you need it", because a number that's a mobile today can be reassigned, and "Old phone numbers are recycled and get reassigned to other people".
• Put a unique index on the E.164 value per customer account. One canonical string is what lets you match a reply to a contact, spot a duplicate and apply an opt-out to every copy of a number.

For display, format from the stored value: 07700 900123 for UK readers, +44 7700 900123 for everyone else. For a link, RFC 3966 says that on a public page "the telephone number in the URI SHOULD always be in the global form, even if the text of the link uses some local format", so the href is tel:+447700900123 whatever the visible text says. The RFC allows dashes, dots and brackets as visual separators inside the URI, but they're ignored for comparison, so the plain form is simplest.

How CaptiFi Connect handles numbers

CaptiFi Connect takes UK numbers in any of the forms in the table above, including +44 (0)7 and a 0044 prefix, parses them with a JavaScript port of libphonenumber, and stores and returns them in E.164, so the to field in every response reads +447 and so on. Mobiles in the UK, Guernsey, Jersey and the Isle of Man are accepted. Anything else comes back in the request's rejected list with a reason, never charged: invalid_number for a number that doesn't parse or validate (drama numbers included), unsupported_destination for another country, and not_mobile for landlines, freephone and premium rate. The errors reference has the full list, and test keys run the same checks without sending anything, which makes them a quick way to see how your list will be read before you spend a credit.