Pattern matching, not understanding
A text extractor works by pattern matching — scanning text for sequences that fit a defined shape, using what's called a regular expression (regex): a formal description of what a valid match looks like, character by character. This is fundamentally different from actually understanding the text's meaning. A regex can recognise that "name@example.com" has the shape of an email address (characters, an @ symbol, more characters, a dot, a short suffix) without knowing or caring whether that address actually exists, belongs to anyone, or is even syntactically complete under every possible rule for what an email address can contain.
Why email addresses in particular have more valid forms than expected
The formal specification for what counts as a valid email address (RFC 5322) is considerably more permissive than most people, and most everyday extractors, assume. It technically allows quoted strings, unusual characters, and structures that essentially nobody uses in practice — a fully spec-compliant email regex is notoriously long and complex, and using one would catch a large number of technically-valid-but-vanishingly-rare forms at the cost of also matching things that merely resemble an email address without being one.
In practice, every real-world email extractor makes a deliberate trade-off between the formally complete specification and a simpler pattern that correctly handles the overwhelming majority of real addresses people actually use, accepting that it will occasionally miss a rare, unusually-formatted address or need adjustment for a specific edge case. This isn't a shortcut taken out of laziness — a fully spec-compliant pattern would also match more false positives, not just more true addresses, since the permissive parts of the specification are permissive in both directions.
Phone numbers have no single format at all
Unlike email addresses, which at least have one formal specification, phone numbers have no single universal format — conventions vary by country for digit count, area code structure, spacing, and whether a country code or leading zero is included. A phone number extractor has to either target one country's conventions specifically (catching that country's numbers reliably but missing or misreading others) or use a broader, looser pattern that catches more international variations at the cost of also matching some sequences of digits and punctuation that aren't phone numbers at all.
| Pattern strictness | Misses valid matches? | Catches false positives? |
|---|---|---|
| Strict, format-specific | Yes - anything outside the expected format | Rarely |
| Loose, general-purpose | Rarely | Yes - things that merely resemble the target format |
What this means when using an extractor
Treat an extractor's output as a strong first pass rather than a guaranteed-complete or guaranteed-correct list, and skim the results for anything that looks off. This is standard practice for pattern-based extraction generally, not a limitation specific to any one tool — the same trade-off applies whether the extraction is happening in a browser tool, a spreadsheet formula, or a full data pipeline, because it comes from the nature of pattern matching against formats that are either more permissive or less standardised than they first appear.
Where this comes from
- The formal email address specification is defined in RFC 5322 (and RFC 5321 for the related SMTP addressing rules); its complexity relative to common informal email-matching patterns is widely documented in software engineering discussions of email validation.
- The lack of a single universal phone number format is addressed by libraries like Google's libphonenumber, whose existence and country-by-country rule tables are themselves evidence of how varied real-world phone number formats are.