Phone Number Validator

A phone number validator answers a deceptively simple question: can this number actually exist? Before you store a number in a database, send it to an API, dial it, or trust a caller ID, it's worth knowing whether the digits even form a structurally legal number under the world's numbering plans. This free tool validates numbers for 190+ countries, strips trunk zeros correctly, catches the fictional and impossible ranges, and hands back the clean E.164 international format that every modern system expects — all in your browser, with no sign-up and nothing logged.

What this validator checks

Validation happens in four structural layers, applied in order. Each one rejects a different class of impossible number.

• Country detection — from a leading + code, a 00 international prefix, or (when neither is present) defaulting to the US/Canada +1 plan. Getting the country right is the foundation, because every subsequent rule depends on it.
• Digit count — the national number is checked against the valid length range for that country. Germany allows a wide range; the US is exactly 10; Singapore exactly 8. A number outside its country's range cannot exist.
• Leading-digit rules — North American area codes and prefixes never begin with 0 or 1; most other countries carry a trunk zero that must be stripped before counting. This layer catches both the "area code starts with 1" impossibility and the "counted the trunk zero as a real digit" error.
• Reserved ranges — the famous 555-0100 to 555-0199 block reserved for film and television, which never reaches a real subscriber. A number here is fictional by design.

A number that clears all four layers is dialable — it fits its country's plan and could be assigned to someone. Whether it currently rings a real person, and who that person is, are entirely separate questions that a validator deliberately does not answer (and cannot, from structure alone). For that, you need the reverse phone lookup.

E.164: the one format every system agrees on

The single most useful thing a validator produces is a number in E.164 format — the ITU international standard. E.164 is simple: a plus sign, the country calling code, then the national significant number, with no spaces, dashes, brackets or leading zeros. (702) 555-2000 becomes +17025552000; 0300 1234567 in Pakistan becomes +923001234567; 07911 123456 in the UK becomes +447911123456.

Why does this matter so much? Because every serious system — CRMs, payment processors, SMS gateways, WhatsApp, two-factor authentication providers — stores and transmits numbers in E.164. Storing numbers in local formats ("0300 1234567") is a recipe for duplicates, failed lookups, and messages that never send. If you build software that touches phone numbers, the rule is: validate on input, store in E.164, and format for display only at the last moment. This tool does the validate-and-normalize step for you.

Phone number formats by country

Every country encodes its numbers differently. The table below shows the calling code, national number length, and an example format for the most-searched countries — the same rules this validator applies. Placeholders like a leading 0 indicate a trunk prefix that's dropped in E.164.

Length ranges and calling codes reflect each country's published numbering plan. Full per-country detail, including carrier prefixes and regional codes, is in the by-country chapter of the homepage guide.

Trunk zeros: the number-one validation mistake

More phone numbers fail validation over the trunk zero than any other single cause. A trunk prefix — almost always a leading 0 — is a digit many countries require when dialing domestically, but which is dropped when the number is written in international form. The UK's 020 7946 0000 is +44 20 7946 0000 internationally; Pakistan's 0300 1234567 is +92 300 1234567; Germany's 030 12345678 is +49 30 12345678.

The mistake people make is either counting the trunk zero as part of the national digit length (making the number look one digit too long) or, worse, storing it in E.164 (+4402079460000 — an invalid number that many systems will reject). This validator strips trunk zeros automatically for every country that uses them. The one deliberate exception is Italy, where the leading 0 of a landline is a genuine part of the number and is retained even internationally (+39 06… for Rome) — a quirk that trips up validators which blindly strip every leading zero.

Fictional and reserved numbers

Some structurally-valid-looking numbers are reserved so they can never reach a real person. The best known is the North American 555-0100 through 555-0199 range, set aside for movies, television and advertising precisely so that a number shouted in a film script doesn't ring a real household. If someone gives you a 555-01XX number as a real contact, you're being quoted a prop. Beyond fiction, other ranges are reserved for testing or future use. A validator that knows these ranges — as this one does — flags them rather than pretending they're ordinary numbers. For a dedicated check of fictional and unassigned numbers, see the fake number checker.

Validating phone numbers in code

If you're a developer, the temptation is to validate phone numbers with a regular expression. Resist it. A regex like /^\d10$/ feels reasonable and is wrong in a dozen ways: it rejects valid international numbers, accepts impossible area codes, mishandles trunk zeros, and breaks the moment your app has a single overseas user. Phone numbering is a genuinely complex, country-specific domain, and hand-rolled regex validation is a classic source of "why can't this real customer sign up?" bugs.

The correct approach is Google's open-source libphonenumber library, which encodes the numbering rules for every country and is maintained as those plans change. It has official ports for Java, JavaScript, Python, C++, Ruby, PHP, Go and more. The same rules this tool applies — country detection, length validation, trunk-zero handling, and E.164 normalization — are exactly what libphonenumber implements, because they're the internationally standardized rules rather than anyone's invention. For a one-off check or a quick sanity test of a number, this validator is faster than writing code; for production input validation at scale, integrate libphonenumber and store the E.164 output.

"Possible" vs. "valid": a subtle but important distinction

Phone-numbering professionals draw a line between two levels of correctness. A number is possible if it has a plausible length for its country — the right ballpark. A number is valid if it additionally matches the specific ranges actually in use — the right area codes, the right mobile prefixes, the reserved ranges excluded. Every valid number is possible, but not every possible number is valid.

This matters in practice. "Possible" validation is more permissive and more stable — it rarely rejects a real number even as numbering plans evolve, at the cost of accepting some numbers that don't correspond to assigned ranges. "Valid" validation is stricter and catches more fakes, but must be kept up to date as countries open new ranges. For a signup form, permissive "possible" validation is often the safer choice (you don't want to block a real customer over a newly-opened prefix your rules haven't caught up to). For fraud screening, strict "valid" checking catches more impossible numbers. This tool leans toward strict structural validity for North America (where it also checks live area-code assignment) and possibility-level checks for other countries, which is the pragmatic balance for a general-purpose validator.

Can a validator tell mobile from landline?

Partially, and it depends on the country. In many numbering plans, mobile and landline numbers occupy distinct ranges — UK mobiles start 07, Pakistani mobiles start 03, French mobiles start 06 or 07 — so the leading digits reveal the line type at validation time. In the North American plan, however, mobile and landline numbers are structurally identical; you cannot tell them apart from the digits alone, which is why you need the carrier lookup (reading the carrier of record) to distinguish a US cell phone from a landline. So a validator can flag line type in countries with separated ranges, but for +1 numbers, line type is a carrier question, not a structural one.

Who uses a phone validator, and why

• Developers and form-builders — validating on input prevents garbage in the database and failed downstream API calls. E.164 output is ready to store.
• Marketers and CRM owners — cleaning a contact list of malformed numbers before a campaign saves money and protects sender reputation.
• Anyone verifying a suspicious contact — a "business" that gives you an impossible number has told you something important before you even call.
• International callers — converting a local-format number you were given into correct E.164 so it actually connects.
• Fraud-aware consumers — an area code that starts with 1, or a number one digit short, is a fast tell that a caller ID was fabricated.

What validation cannot do

A validator is a structural check, and honesty about its limits is what keeps it useful. It cannot tell you whether a valid number is currently assigned to anyone — only a live network (HLR/HLR-lookup) query can confirm that, and it isn't free. It cannot name the carrier, owner or location — those are separate lookups. And it cannot tell you whether a number is safe to trust; a valid number is spoofable and can be actively used for fraud. Treat validation as the first gate — "could this exist?" — and the reverse phone lookup as the second — "what is it, and has anyone reported it?"

Frequently asked questions