UK Phone validators for checking and formatting numbers

Why format is not enough

A mobile issued to a customer in 2014 and disconnected in 2019 still matches every structural rule today, so it remains in your CRM even though it delivers nothing.

So what does "valid" actually mean? Two different things depending on the context, which is the source of the confusion. One meaning is structural plausibility, which asks whether the digits could belong to a real UK line. The other is evidence that a line is live right now and can receive a call or message. A network response can also come back inconclusive, which means the provider could not confirm either way and you have to decide how to treat that record.

This matters whether you collect numbers through web forms or clean up years of accumulated CRM and campaign data. You need both checking and normalization from a phone validator, because a single regex test tells you almost nothing about whether the person on the other end will ever hear from you.

How phone validators in the UK work

A useful phone validator applies two layers, and they answer different questions. The first parses the input against UK numbering rules and decides whether the digits form a plausible number. The second queries carrier or network data to find out whether that number is assigned and active. Confusing the two is the most expensive mistake in this space.

A structurally valid result should never be treated as contactable on its own, because numbers can become inactive when people change carriers or cancel plans, and none of that changes the shape of the digits.

You have to know which question each layer answers and run the right one at the right moment.

Telephone number validation checks

The first layer checks whether a number conforms to the structure of the UK plan. It checks the country code and the national trunk prefix. It also checks the digit count and whether the digits fall inside an allocated range that looks like a mobile or a geographic number. A good phone validator parser accepts messy input first, so spaces, brackets, and both national and international formats can go in, and clean normalized numbers come out.

Google's open-source libphonenumber library is the reference implementation many teams build on, and its "max" metadata even returns the line type where the range allows it. Telephone number validation establishes only that a number could be valid. This layer establishes only that a number could be valid. It's a cheap check that requires no network and belongs at the point of data entry.

UK mobile ranges give you a concrete anchor here. According to Ofcom's National Telephone Numbering Plan, mobile telephony sits on 071 to 075 and 077 to 079, with 070 reserved for personal numbering that people mistake for mobiles and 076 used for pagers. A parser that treats every 07 number as a mobile will misclassify those ranges, so the allocated-range check matters as much as the digit count.

Carrier and HLR lookups

The second layer goes to the network. A carrier lookup and a Home Location Register (HLR) lookup query mobile operator data to tell you whether a line is assigned and active, and which carrier serves it. A typical HLR response returns a status such as LIVE, DEAD, or ABSENT_SUBSCRIBER and a line type of MOBILE, LANDLINE, or VOIP. It also returns the current carrier and whether the number has been ported.

That second layer is where telephone number validation earns its keep in a campaign. Filtering an SMS list on LIVE status and MOBILE line type removes the disconnected numbers and the landlines before you spend a penny sending. One caveat you cannot skip: HLR data applies mainly to mobile numbers since landline and VoIP numbers are not registered in the HLR at all. Read a phone validator service's own definitions and confirm its UK coverage, because a result of "unknown" is not the same as "dead."

Apply UK number formats

Once a number is accepted, you have two formatting jobs that people constantly conflate. One is the human-readable version you show on screen. The other is the single canonical value you store in your system. Keep them separate and most formatting bugs disappear.

Format UK mobiles

A UK mobile displays nationally as 07XXX XXXXXX and internationally as +44 7XXX XXXXXX. The conversion to +44 removes the leading trunk prefix 0, so the national number becomes the international. Your phone validator parser should tolerate input that arrives messy but recoverable. Handle these cases:

• Numbers padded with spaces or wrapped in brackets, such as (07911) 123 456

• A number entered without any country code when the form has already established GB as the country

Format London landlines

London numbers display nationally as 020 XXXX XXXX and internationally as +44 20 XXXX XXXX. The point that trips up developers is that 020 is the complete London area code, full stop. Ofcom research once found that only 13% of people correctly identified 020 as London's single code, with most assuming 0207 and 0208 were separate codes. They never were.

Do not group the first digit of the local number as part of the area code. The same leading-zero rule applies when you add the country code: drop the 0, prepend +44.

Format other geographic numbers

Other UK geographic numbers begin 01 or 02, and their national spacing varies with the length of the area code and the local number. Don't assume one visual grouping fits every range. Cardiff on 029 groups as (029) XXXX XXXX. Bolton on 01204 groups as (01204) XXXXX. Sedbergh on 015396 groups as (015396) XXXXX, according to the officially approved Ofcom number groups.

Rely on maintained UK numbering metadata for display spacing. Area codes in the UK range from three to six digits, and no single spacing pattern covers all of them.

Store numbers in E.164

Whatever a number looks like on screen, store one canonical value in E.164 format.

Use +44XXXXXXXXXX as your model structure. The common broken conversion is +440XXXXXXXXXX, which keeps the trunk 0 and produces an unroutable number. Store the canonical value once and use it to generate the national and international display versions.

Choose a phone validator in the UK

Match the service to your deployment need. Here's how five real options line up when you organize the choice of a phone validator around those needs:

Acudo brings HLR lookup and TPS Unlimited into one unified solution, while also providing e164 formatting. It supports real-time API and bulk processing, and its line type and carrier insight includes ported-number detection aimed at contactability.

Beyond that starting point, weigh a provider on:

• Coverage of your actual number ranges. HLR data is strongest for mobile; confirm how a provider handles landline and VoIP separately rather than folding them into one generic "valid/invalid" result

• How provider treats "unknown." Check whether the provider exposes that state distinctly or silently collapses it into a pass or fail

• Ported-number handling. Carrier data based on original allocation can still show a customer's previous operator after a port; ask whether the provider resolves to the current serving network

• Deployment fit. Real-time API for point-of-entry checks, bulk processing for list hygiene, or both — match the mode to whether you're validating at collection or cleaning an existing database

• Rate limits, latency, and pricing against your actual send volume

Before you assign any capability from a marketing page, verify each provider's current UK coverage and response definitions. Also verify rate limits and latency. Check pricing and how it handles inconclusive results. A provider that classifies a carrier by original allocation rather than the current serving network can still show the previous operator on a ported number.

Keep in mind that marketing permission requires a separate check from phone validity. A live-status check proves a number is reachable, but it says nothing about whether you're legally allowed to make a marketing call to it.

Build the validation flow

A reliable phone validator flow is a short sequence you can wire into a form or a batch job. The order matters because each step depends on the one before it.

1. Keep the raw input exactly as the user typed it, in its own field, so you can troubleshoot later.

2. Parse it with GB context so a number without a country code is still understood as UK.

3. Reject structurally impossible input at this stage, before it reaches the database.

4. Normalize every accepted number to E.164 and store that as the canonical value.

5. Run a live lookup when contactability actually matters, either immediately or right before an outbound campaign.

A low-friction telephone number validation check suits form entry, where you want to catch typos without slowing the user down or paying for a network query on every keystroke. A deeper HLR lookup belongs where the cost of a failed send is real. Run it before an SMS campaign. Use it for an OTP push or a batch of service alerts. Store the E.164 number alongside its validation status, a timestamp, the line type, and the provider response, so you can see when a number passed and on what evidence.

Add a periodic bulk-cleaning step, because a number that was live when you collected it can go dead later. UK mobile providers recycle inactive numbers within a 70 to 180 day window, which means a clean list slowly rots if you never re-check it. This is where telephone number validation shifts from a one-time gate to an ongoing hygiene routine, and where a bulk HLR pass earns its cost by pruning the dead records before your next send.

Avoid common validation mistakes

Most failures come from a handful of predictable errors, and they undermine otherwise solid implementations. Regex alone tops the list. A pattern can confirm that digits look like a UK number, but it cannot confirm the range is allocated or the line is live, so treating a regex pass as "contactable" guarantees wasted sends.

The +440 error is the next most common. A UK E.164 number never keeps the trunk 0 after +44. Normalization must also happen before deduplication and storage, because +44 XXXX XXXXXX and 0XXXX XXXXXX are the same line, and if you dedupe before normalizing you'll keep both as separate records. Watch out for these traps in particular:

• Storing a number with an extension, such as 0XX XXXX XXXX x123, mixed into the base number. Parse and store the extension in a separate field so it doesn't corrupt validation or dialing.

• Treating an "unknown" lookup result as dead. Unknown means the network could not confirm, so flag it for follow-up rather than deleting the record.

• Assuming line type never changes. Ported and reassigned numbers shift over time, which is why a stored status needs a date.

• Mixing national and international values in the same database field

Each of these is cheap to prevent at design time and expensive to unpick once millions of records carry the flaw.

Test before launch

Before you deploy, run the phone validator against a representative set of test cases and confirm it handles each one. Build your test suite to cover a UK mobile and a London landline. Include another geographic number on a longer area code and a correctly formatted international number. Test malformed input and an inactive number. Add a duplicate and one carrying an extension. Then confirm the validator returns and stores every provider response state, including inconclusive.

If contactability sits at the center of your operations, speak to Acudo about mobile validation workflows before your next campaign, and close the gap that a plain phone validator was never built to catch.