Phone Number Extensions: Parsing and Storage Guide

An extension routes within an organization or PBX. It is not part of the public E.164 telephone number and should have its own field and validation rules.

Separate the public number from the extension

Store +12025550123 as the canonical public number and 456 as a separate extension. Do not append the extension to E.164, apply country numbering rules to it or include it in an SMS destination.

A practical form can offer one phone field and one optional extension field. If pasted input contains markers such as ext, extension or x, parse them conservatively and show the result before saving.

Represent extensions in tel URIs

RFC 3966 uses the ext parameter: tel:+12025550123;ext=456. The extension parameter identifies a station behind a PBX and remains distinct from the global phone number. Read the normative RFC 3966 specification for parameter syntax and comparison rules.

A tel URI identifies a telephone resource; it does not guarantee that every device will automatically send extension digits after a call connects. Test the behavior on the platforms your users actually use.

Model extension rules locally

Extensions belong to an organization's private routing plan, so there is no universal global length. Define permitted characters and length from your own PBX or product requirements. If only digits are supported, say so in the field hint and reject other characters without changing the public number.

Database and API shape

{
  "phoneE164": "+12025550123",
  "extension": "456",
  "verifiedAt": null
}

Keep verification state separate as well. Verifying the public number does not necessarily prove access to every extension, and an extension can change without the public line changing.

Extension test checklist

Missing extension remains valid when optional.
Leading zeros are preserved when the PBX treats them as significant.
Overlong input produces a specific extension error.
SMS and OTP integrations receive only the public E.164 value.
Display formatting and tel links include the extension only where supported.

See the broader phone-number database guide for storage and uniqueness decisions.

Support and billing edge cases

Extensions often belong to companies, hospitals, schools and support centers. A user may share the same public number with many colleagues while only the extension changes. Store that relationship explicitly so duplicate detection, billing contacts and account recovery do not collapse unrelated people into one record.

If your system sends SMS, strip extensions before delivery and keep the extension only for voice workflows that can use it. If your system displays a tel link, verify how target platforms handle the extension parameter instead of assuming every dialer behaves the same.

How this guide connects to the toolkit

This page is written as an implementation reference, not a generic glossary. Use it with the interactive tools when you need to turn an idea into a testable behavior: generate a fixture, format it, validate the structural claim, then record the country and expected result beside your product test. Keeping the explanation and tool output connected helps future reviewers understand why a number was accepted or rejected.

If you copy an example into your own documentation, also copy the safety context. A phone string without its country, source note and limitation can look like a contactable number. The surrounding guidance is part of the value of the fixture.