What is checked?
Country calling code, national digit count and a small set of well-known prefix constraints. The input is normalized before those checks so spaces, parentheses and hyphens do not decide the result.
Free validation tool
Phone number validator
Check a phone number against basic country-specific length and prefix rules. Nothing you enter is sent to GetPhoneNum.
Validate a number
Country
National digits
E.164
Assessment
Structural validation only: a passing result does not prove that the number is assigned, reachable or safe to contact.
What is not checked?
Live assignment, carrier, line type, number portability, ownership and SMS or voice capability. Those questions require current numbering metadata, provider data or a consent-based verification flow.
Need another format?
Use the E.164 formatter for national, international and RFC 3966 output.
How to interpret a result
| Result | Meaning | Safe next step |
|---|---|---|
| Passes structure | The digits fit the basic rules included for the selected country. | Store a normalized value, then apply any production checks separately. |
| Wrong length | The national digit count falls outside this tool's supported pattern. | Ask the user to review the country and input; do not silently pad or trim digits. |
| Unsupported | The country or range needs more detailed metadata than this lightweight checker contains. | Use a maintained numbering library and preserve the original input for correction. |
Recommended validation workflow
Parse with an explicit country context, normalize to E.164, apply current structural metadata, and keep reachability or ownership verification as a separate step. Record verification status independently from the phone string so formatting changes cannot accidentally mark a user as verified.
Validation policy for product teams
Write down which claim your product actually needs before you reject a phone value. A newsletter signup may only need a parseable format. A billing profile may require a supported country. A security recovery flow may require proof that the user controls the number. These are different product rules and should not share one vague error.
A practical policy separates four fields: the raw input for correction, the normalized E.164 value for storage, the selected or parsed country, and the verification state. That model lets support teams explain failures and lets engineers update numbering metadata without rewriting historical records. It also prevents a dangerous shortcut where a display formatter accidentally becomes an identity check.
Examples worth testing
- A valid national input with punctuation, such as a number pasted from an email signature.
- The same destination in E.164 form, proving that deduplication happens after normalization.
- A number that is one digit too short and one that is one digit too long.
- A value with a correct calling code but a country your product does not support.
- An extension that must be stored separately rather than appended to the public number.
- A value that parses but still requires OTP or call verification before account recovery.
Use the testing checklist and country dataset to keep those cases reproducible.
What this validator intentionally does not do
The tool does not contact carriers, query subscriber databases, identify the owner of a number or check whether a destination can receive SMS. Those claims change over time and require live provider data, consent and privacy controls. Keeping this page limited to structural validation makes the output honest: it can help developers catch formatting mistakes, but it will not encourage users to treat a generated or pasted number as verified personal information.
Review checklist before relying on a result
Before using a validation result in a release, confirm the country selector, expected national length, E.164 conversion and error message all describe the same rule. Then test the same input on the server path that stores or sends the value. If the client accepts a value that the server rejects, users will see inconsistent behavior; if the server accepts a value the client rejected, QA may miss the real production contract.
Keep that contract in your test plan, not only in a form placeholder.