The basic global form
A global telephone URI starts with tel: followed by a plus sign, country calling code and national significant number. For example, tel:+12025550123 represents the E.164 fixture +12025550123. Visual separators may improve readability, but the canonical link can remain compact.
Use the E.164 formatter to produce an RFC 3966 representation from national input.
Keep extensions as parameters
An extension is not part of the E.164 number. RFC 3966 represents it with the ext parameter, for example tel:+12025550123;ext=456. Store the canonical phone number and extension separately so routing logic can decide when the extension applies.
Do not append an extension to the digit string and then send that combined value to an SMS API.
Global and local numbers differ
A local-number URI lacks a country calling code and needs a phone-context parameter to make its scope meaningful. For public web pages and cross-border applications, a global form is usually easier to interpret. Internal systems may use local forms only when the context is controlled and explicit.
Implementation checklist
- Parse and normalize user input before building the URI.
- HTML-escape attribute values.
- Keep extension and phone context separate from the core number.
- Test the link on target mobile and desktop platforms.
- Do not assume clicking proves reachability or consent.
Read the normative IETF RFC 3966 specification for parameter grammar and comparison rules.
Where tel links are useful and where they are not
A tel link helps users hand a phone number to their device's dialer. It is appropriate for contact pages, support documentation and mobile-friendly account screens. It is not a verification mechanism: a click does not prove the destination exists, the call completed or the user controls the number.
Test tel links on the devices and browsers your users actually use. Desktop browsers, mobile browsers and installed communications apps may handle extensions and pause characters differently. Keep the underlying E.164 value separate so display experiments do not corrupt the stored contact field.
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.