How to Validate Phone Numbers in a Pasted List Before You Send

The number that breaks your SMS blast is never the one that looks broken. It is the one that looks fine: ten digits, a dash in the right place, copied straight out of a spreadsheet a coworker swears is clean. So before I import a contact list or hand it to a script, I run it through a check that does one boring, honest job: it reads each line as a candidate phone number and tells me, row by row, whether the digit count makes sense.

That is what the Phone Number List Validator does. Paste a list, and it parses every line locally in your browser, then hands back a pass/fail report with a reason printed next to each row. No upload, no carrier query, no guessing. This post walks through what "valid" actually means here, where the digit-count rules come from, and the trap that catches most teams: a number can pass the check and still ring nobody.

What this tool checks, and what it does not

Let me be exact, because the difference matters when you act on the output. This validator works on shape, specifically the count of digits in each entry. It strips formatting noise, counts the digits, and flags any line that falls outside a sensible range for a real phone number. It does not call a carrier, it does not ping a HLR database, and it does not confirm the line is connected or owned by anyone. It is a structural check, not a liveness check.

The reason that boundary exists is honesty about what runs in a browser tab. A carrier lookup needs a paid network query to a telecom database. A digit-count check needs nothing but the text you pasted, which is exactly why the whole pass stays local and the numbers never touch a server. You get a fast, private filter that removes the entries no carrier could ever route, and you keep the human judgment for everything past that.

The digit-count rules, grounded in E.164

The maximum is not arbitrary. The international standard for phone numbers, E.164, caps a full international number at 15 digits, country code included. That is a hard ceiling: no assignable number on Earth is 16 digits long. So an entry that counts to 16, 18, or 20 digits is not a long number, it is a wrong one, usually two numbers glued together or a stray ID column that leaked into the phone field.

The floor is the mirror image. A real phone number has a sensible minimum length, so a 4-digit or 5-digit entry is not a short number, it is a fragment, an extension, or a typo where someone fat-fingered half the value. Both ends get flagged. A 4-digit row fails as too short. A 20-digit row fails as too long. Everything between the floor and the 15-digit ceiling passes the shape check, and the reason column tells you precisely which rule each failure tripped.

What the validator does not assert is just as important: passing the digit range means the entry could be a phone number, not that it is a working line. E.164 conformance is a syntax test. Assignment, activation, and reachability live in the carrier's records, not in the character count.

A worked example

Here is a small list, the kind that shows up after someone pastes three exports into one column:

+1 415 555 0199
415-555-013
+44 20 7946 0958
8613800138000
1800
+1 415 555 0199 ext 4471 0022 8890

Run it through the validator and the report reads like this:

| Input | Result | Reason | |---|---|---| | +1 415 555 0199 | valid | 11 digits, within range | | 415-555-013 | invalid | too short — 9 digits, one digit shy | | +44 20 7946 0958 | valid | 12 digits, within range | | 8613800138000 | valid | 13 digits, within range | | 1800 | invalid | too short — 4 digits | | +1 415 555 0199 ext 4471 0022 8890 | invalid | too long — 21 digits, exceeds E.164's 15-digit cap |

Three pass, three fail, and each failure carries a reason you can act on. The 415-555-013 row is the dangerous one. It looks like a real US number until you count and land on nine digits, one short. The ext row is two numbers and an extension mashed together, blowing past 15. The validator does not silently drop the bad rows to flatter the pass count. It keeps them, with reasons, so you can hand them back for repair instead of shipping a list that half-works.

Why valid shape is not a working line

This is the part I wish more people internalized before a launch. The validator can tell you +1 415 555 0199 has a legal digit count. It cannot tell you that line is connected, that it belongs to the person in your CRM, or that it was not ported away last month. Shape and reachability are different questions, and only one of them is answerable from pasted text.

So treat a pass as "cleared for routing format," not "confirmed reachable." A passing list is one where every entry is structurally capable of being a phone number, which means your send tooling will not choke on garbage and your invalid-entry bounce rate drops to the entries that fail for real-world reasons. That is a meaningful win, but it is a different win than "every number works." If you need true deliverability, that comes from a sending platform's response codes, not from a character count.

Where this fits in a cleanup workflow

Validation is rarely the only step. In practice I chain a few tools. If a column is buried inside a messy export, I pull the values first with the Phone Number Extractor, which lifts numbers out of logs, HTML, and pasted pages while keeping source line numbers. Then I run the validator to flag the malformed rows, and only after that do I worry about format consistency or duplicates downstream.

The validator itself also does more than fail rows. You can keep unique entries only, preserve invalid rows for review, sort the normalized output, and export the result as CSV, JSON, Markdown, a SQL IN list, or a TypeScript union, so the artifact you download is the exact shape your next step needs. When you want an audit trail, download CSV or Markdown with the reason column intact rather than copying just the final list, because the reasons are the evidence that the cleanup happened.

The short version

Validating a phone list is a digit-count discipline. E.164 caps an international number at 15 digits, a real number has a sensible floor, and this tool flags anything outside that range with a reason beside the row, all locally, never sent to a server. The 4-digit fragment and the 20-digit collision both fail. The clean-looking 9-digit typo fails too, which is the whole point. Just remember the ceiling on what the check can promise: a passing number is correctly shaped, not confirmed working. Use the validator to clear the format, then let your sending platform answer for reachability.

---

Made by Toolora · Updated 2026-06-13