La Ventana, Baja California Sur, México. [email protected]
←Journal
·7 min read

Click-to-Call Links on Service Sites: Formatting tel: Numbers

A click-to-call link looks trivial until it dials the wrong number for a visitor in another country. Here is what the tel: standard and the international numbering plan ask for, how phones handle the link, and a short checklist for getting it right.

Windware Studio· Design & Development Team

For many service businesses, a phone call remains one of the most direct routes from a visitor’s question to a booked job. On a phone screen, that path depends on one small piece of markup: a link that hands the number to the dialer. When the link is missing, the visitor has to copy the digits by hand. When it is written carelessly, it can dial nothing at all, or the wrong number.

Click-to-call links follow a published standard, the tel: URI scheme defined by the Internet Engineering Task Force (IETF) in RFC 3966. This article reads that standard alongside the international numbering plan it builds on, ITU-T Recommendation E.164, and the developer documentation Apple and Android publish for phone links, to show how to write a number that works for every visitor who taps it.


Why a phone number needs more than text

A number printed as plain text works for anyone willing to retype it. A link removes that step, but only if the address inside it is complete. The visible text and the address in the href attribute do different jobs: one is read by a person, the other is passed to software that has to place a call.

  1. The address is written in local format. A link such as tel:5550123 relies on the caller’s phone to supply the missing area and country codes. A visitor travelling, or calling from another country, can end up with an incomplete or wrong number.
  2. The link text hides the number. A button that says only “Call us” gives no way to check the number before tapping, and no number to copy on a laptop that cannot dial.
  3. The browser guesses. Apple’s Safari documentation notes that Safari on iOS, by default, detects any string formatted like a phone number and turns it into a call link. Order references, case numbers, or other long digit strings can become links nobody intended.

A tel: link is an address for a telephone number, in the same way an https: link is an address for a web page. RFC 3966, written by Henning Schulzrinne of Columbia University and published in December 2004, defines how that address is spelled. It describes a telephone number as an identifier, and leaves the dialing itself to the device: the dialer knows whether it needs an international prefix, an outside line, or tone dialing.

On a phone, following the link opens the dialer rather than calling straight away. Apple’s developer documentation says that when someone taps a telephone link in a web page, iOS asks whether they want to dial the number and calls only if they accept. Android’s developer guide describes a similar pattern for apps that pass a tel: address to the system: the phone app opens with the number filled in, and the user taps Call. The standard requires this restraint. RFC 3966 says software must not use a tel: address to place a call without the user’s explicit consent, because calls can cost money and reveal the caller’s own number.

Global numbers and local numbers

The standard recognizes two kinds of number. A global number starts with +, then the country code, then the national number, following ITU-T Recommendations E.123 and E.164. RFC 3966 calls these numbers “unambiguous everywhere in the world” and says they should be used. A local number is one that only makes sense in a particular place, such as an emergency code or an internal extension, and the RFC requires it to carry a phone-context parameter saying where it is valid.

A global number works like an international mailing address that already includes the country line. Whoever handles it, wherever they are, has everything needed to route it. The comparison stops at routing: the + itself is not dialed. RFC 3966 notes that it signals that an international prefix is required, which in many countries is 00.


RFC 3966 is direct about public web pages: the number inside the link “SHOULD always be in the global form, even if the text of the link uses some local format.” Its own example pairs a familiar U.S. display format with a global address:

<a href="tel:+1-201-555-0111">(201) 555-0111</a>

The details that follow come from the same standard and from E.164, which the International Telecommunication Union (ITU) last revised in February 2026.

  • Separators are optional and cosmetic. Hyphens, dots, and parentheses are allowed as visual separators. The RFC says they “merely aid readability” and are ignored when placing a call.
  • No spaces in the address. ITU-T E.123 recommends spaces in printed numbers, but RFC 3966 says tel: addresses must not use them. Keep spaces in the visible text if you like, and leave them out of the href.
  • Drop the national trunk prefix. Many countries add a leading digit for calls within the country, commonly 0, the digit ITU recommends for the purpose. E.164 states that this national (trunk) prefix is not part of the number at the international level and must not be dialed from abroad. When you convert a number to + form, check whether its leading digit is a trunk prefix and remove it.
  • No letters. A number that spells a word is fine as visible text, but the RFC’s address format does not support letters, so the href needs the digits.
  • Do not rely on length rules. E.164 recommends that international numbers have no more than 15 digits, not counting the international prefix. RFC 3966 adds that software must not assume a fixed, minimum, or maximum length, so the same caution applies to any phone validation on your forms.
What you showWhat goes in the hrefWhy
(201) 555-0111tel:+1-201-555-0111Global form works for callers anywhere (RFC 3966, section 8)
201 555 0111tel:+1-201-555-0111Spaces are fine in text but not allowed in the address
Call 1-555-IETF-RFCtel:+1-555-438-3732Letters are not part of the address format
Call ustel:+1-201-555-0111Works, but hides the number; show the digits beside it

The numbers in this table are the fictional examples used in RFC 3966.

“The link text is for the person reading the page. The address is for the phone that has to place the call. Write each one for its reader.”
— Windware Studio Practice Note


Limits and tradeoffs

Phones are often more forgiving than the standard. Android’s developer guide lists tel:(212) 555 1212, spaces included, as a valid example and notes that the dialer is good at normalizing numbers. Apple’s own sample link, tel:1-408-555-5555, omits the +. Lenient handling on one phone is not a reason to write a loose address. The global form is the only one the standard says will mean the same thing everywhere.

The platform documentation also has gaps. Apple’s phone-link page sits in its documentation archive and was last updated in 2017, so its description of iOS behavior should be checked on a current device. Apple says the Phone app will not dial a link containing * or #, which rules out links that try to step through a phone menu. RFC 3966 defines an extension parameter (;ext=), but neither Apple’s nor Android’s pages cited here explain how their dialers treat it. If callers need an extension, print it next to the link.

Desktop behavior varies most. Apple documents that FaceTime on macOS 10.10 and later can place a call through a connected iPhone. Other computers open whichever app, if any, is registered for tel: links. That is one more reason to keep the digits readable as text.

Finally, RFC 3966 raises two risks site owners rarely consider. Link text can disguise the number it dials; the standard’s own warning example labels a premium-rate link “Find free information here.” And because tel: marks a number as a phone number, it may make the number easier to harvest. For a business number that is meant to be public, that risk is small, but it argues against marking up staff mobile numbers.


The studio approach: a click-to-call check

  • List every phone number on the site, including headers, footers, contact pages, and location pages.
  • Convert each to global form: +, country code, national number, no trunk prefix, no spaces.
  • Use the visible number as the link text, formatted the way local visitors expect.
  • Print any extension or calling hours as text beside the link.

Phase B: Test before launch

  • Tap each link on at least one iPhone and one Android phone and confirm the dialer shows the right number.
  • Open the page on a desktop browser and confirm the number is readable and copyable.
  • Scan long digit strings, such as reference or license numbers, for unwanted automatic links on iOS; if they appear, add <meta name="format-detection" content="telephone=no"> and keep explicit tel: links for real numbers.
  • Confirm the number in the links matches the number in your business listings and structured data.

Practical takeaways for your next website

  1. Write the address in global form, with + and the country code, as RFC 3966 recommends for public pages.
  2. Keep spaces and letters out of the href, and keep the friendly format in the visible text.
  3. Remove the national trunk prefix when converting a local number, as E.164 describes.
  4. Show the number as the link text, so visitors can check it and desktop users can copy it.
  5. Test on real devices, because platform behavior, extensions, and desktop handling are not fully documented.

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.