Phone Number Extractor

Stripping the punctuation is not normalizing

The common approach is to add a column holding the digits with the brackets and dashes taken out. That is not normalization, and you can see why with one example. Here is the same London landline three ways, and the same New York number three ways:

written              digits only        E.164
020 7946 0018        02079460018        +442079460018
+44 20 7946 0018     442079460018       +442079460018
00 44 20 7946 0018   004479460018       +442079460018

(415) 555-0134       4155550134         +14155550134
415.555.0134         4155550134         +14155550134
+1 415 555 0134      14155550134        +14155550134

In the digits-only column, six values. In the E.164 column, two. If you deduplicate on digits-only you remove one duplicate out of four. If you feed digits-only to a messaging API it rejects most of them. E.164 is the only representation where the same phone is the same string.

Getting there needs a default country, which is why that is the first control on the page. A number written 020 7946 0018 is only meaningful next to the knowledge that it is British; the same digits mean nothing in the United States, where numbers do not start with a zero.

Not everything with digits in it is a phone number

An extractor that matches any run of digits turns every invoice number, order id, date range and dollar figure in the document into a phone number. This one requires at least seven digits inside a run made of digits and the usual separators, which is the shortest plausible national number, and then checks that the result lands between eight and fifteen digits once the country code is on it. Fifteen is the E.164 maximum and it is a hard rule, not a heuristic.

On the sample, that means:

• 020 7946 0018, 07700 900123, (415) 555-0134 and the rest are found.
• Invoice 12345 and ticket 987654 are not: six digits is below the floor.
• 2026-09-03 is not: eight digits, but they normalize to a fifteen-digit international number that fails the length check for the default country, and the reason says so.

You will still get the occasional false positive from a long reference number. The Drop what will not normalize option is the lever: leave it off and everything comes through with an empty E.164 column for the ones that failed, so you can see and judge them. Turn it on and the output holds only numbers that resolved cleanly.

What this cannot tell you

Whether the number is assigned, whether it is a mobile or a landline, and who it belongs to. All three need a carrier database, and any tool that claims them from a regular expression is inferring from number ranges that change. What you get here is the format right, consistently, so that the system you feed it to can do its own lookup.

The country column is a genuine inference from the calling code and is reliable, with one caveat worth knowing: +1 covers the United States, Canada and about twenty Caribbean territories, so a +1 number is reported as US because that is the first match on the list. If the distinction matters, the area code is the thing to look at and this page leaves it intact for you.