You're on your phone, you find a plumber's website, and there's the number — big bold text, right at the top. You tap it. So you copy, switch apps, paste, hit dial. And somewhere between step two and step three, a chunk of people just...
The business never knows. That's the quiet tragedy here. They paid for the website, they got the SEO right, someone actually landed on the page — and then the phone number was just decorative text.
Daniel sent us this one. He's pointing at a standard most people have never heard of — E dot one six four — combined with something called the tel URI scheme. It's the difference between a phone number you have to manually dial and one that's a single tap on a mobile screen.
He's got a very specific technical question buried in there too. Why do you drop the leading zero when you convert to E dot one six four, but keep zeros that appear later in the number? That's not a trivial question — it gets at how the whole international numbering plan actually works.
The setup is: millions of small business websites are quietly bleeding leads because of a five-minute fix nobody told them about. And the fix itself is this invisible piece of infrastructure that's been holding the global phone system together for decades.
Which is exactly the kind of thing that makes me unreasonably excited. A standard that does one thing perfectly, that nobody thinks about, and that silently costs you money when it's missing.
You're going to tell us why the leading zero has to go.
I am absolutely going to tell you why the leading zero has to go.
E dot one six four. It's an ITU-T standard — that's the International Telecommunication Union's standardization arm — and it defines what's called the international public telecommunication numbering plan. Which is a very bureaucratic way of saying: it's the rulebook for how phone numbers work globally.
The rulebook nobody reads but everybody uses.
And it specifies three things that matter for this conversation. First, a maximum of fifteen digits for any phone number anywhere on earth. Second, every number starts with a country code — plus one for the US and Canada, plus forty-four for the UK, plus eighty-one for Japan. And third, after that country code comes something called the national significant number, which varies in length by country.
Fifteen digits seems arbitrary. Why not sixteen?
It was chosen to fit within the signaling protocols of the era — specifically SS7, the system that routes calls between carriers. Fifteen digits plus a few overhead bytes fits neatly into the message formats they were working with in the nineteen eighties when this was standardized. And it's held ever since.
It's a technical constraint that became permanent infrastructure. Like the width of Roman roads determining railway gauges.
That is a deeply Corn observation and I'm going to resist the urge to spend ten minutes on it.
Now the question Daniel actually asked: the leading zero. Why does it get dropped?
So in most countries outside North America, when you dial a number domestically, you start with a zero. That zero is called the trunk prefix. It tells the local exchange "this is a national call, route it accordingly." It's a domestic signaling mechanism — it has no meaning outside the country's own network.
It's like an internal memo that accidentally got printed on the letterhead.
That's exactly what it is. When you're calling from outside the country, you don't need that internal routing instruction — the plus and the country code replace its function entirely. So you strip it. Take a London number: zero two zero seven nine four six zero one two three. The leading zero is the trunk prefix. Drop it, prepend plus forty-four, and you get plus forty-four twenty seven nine four six zero one two three.
The zero inside "seven nine four six zero one two three" — that stays.
That stays because it's part of the subscriber number. It's not signaling anything about routing, it's just a digit in the actual phone number. Same logic in Japan: zero three one two three four five six seven eight becomes plus eighty-one three one two three four five six seven eight. The leading zero is the trunk prefix for Tokyo, the rest of the digits are the actual number.
The US just... doesn't do this.
The North American Numbering Plan countries — US, Canada, and about twenty Caribbean nations — never used a trunk prefix. You dial two one two five five five one two three four directly, even domestically. So converting a US number to E dot one six four is mostly just prepending plus one and stripping any parentheses or dashes. It's simpler, which is probably why American developers sometimes miss this whole leading-zero issue entirely when building for international audiences.
Which means a UK number displayed on a site built by someone in California might keep its leading zero in the link, and that link just breaks for anyone outside the UK.
The link doesn't throw an error, it just doesn't connect. And the business owner in London never finds out.
That's the number format itself. But E dot one six four on its own is just a specification — it doesn't make anything clickable. For that, you need the tel URI scheme, which is defined in RFC three nine six six, updated by RFC five three four one.
This is where the web meets the phone network.
The syntax is brutally simple. You write "tel colon" then a plus sign, then the country code, then the national significant number — all in E dot one six four format, no spaces, no parentheses, no dashes, no leading zero. So that London number becomes tel colon plus forty-four twenty seven nine four six zero one two three. On a mobile browser, that renders as a tappable link that opens the phone dialer with the number pre-filled.
If you leave spaces in there?
It works on some browsers and breaks on others. The MDN web docs are explicit about this — the tel URI must contain a global number in E dot one six four format. Formatting characters are not part of the standard. iOS Safari tends to be forgiving, some Android browsers less so, and desktop behavior is all over the place. The spec says strip everything.
The safe move is to treat the tel link as machine-readable only, and display whatever human-friendly format you want between the anchor tags.
The visible text can say "zero two zero seven nine four six zero one two three" with spaces and parentheses and whatever makes sense locally. The href is pure E dot one six four. They're independent.
What about extensions? Daniel mentioned phone trees.
The MDN docs cover this too. You can append an extension using a semicolon and "ext equals" — so tel colon plus one two one two five five five one two three four semicolon ext equals one zero one. That's the modern syntax. There's also an older approach using the letters p and w — p inserts a one-second pause before dialing the next digits, w waits for user confirmation. So tel colon plus one two three four five six seven eight nine zero semicolon p equals one would pause, then dial extension one. This is genuinely useful for businesses. A customer taps the number, the phone dialer opens, and it automatically navigates the phone tree.
Which means you could put your entire "press two for billing" path into the link.
I'm not sure I'd recommend encoding a seven-layer phone tree into a URI, but technically you can chain multiple pauses. It's the kind of thing that's either a power move or a cry for help.
Those aren't mutually exclusive.
Now let me come back to the leading zero question, because there's a nuance here that trips people up. The reason you drop the leading zero but keep internal zeros is about what that digit actually represents. The leading zero is not part of the phone number — it's an instruction to the domestic switching equipment. It says "this call is staying inside the country, route it on the national trunk network." When you dial from abroad, you're not on that domestic trunk network, so the instruction is meaningless. The plus and the country code serve the same routing function at the international level.
It's not that the zero is "wrong" — it's that it's metadata for a system the international caller isn't using.
And the zeros that appear inside the subscriber number — like the zero in "seven nine four six zero one two three" — those are just digits. They're not signaling anything. They're part of the address. The distinction is functional, not cosmetic.
Which means someone who blindly strips every zero from a phone number is going to produce a number that doesn't work.
That mistake does happen. I've seen it in hastily written number-formatting scripts. Someone hears "drop the leading zero" and writes a regex that nukes all zeros, or all zeros after the country code. It's the kind of bug that doesn't surface until an international customer complains — and most of them just give up instead.
The Twilio glossary you mentioned — they're pretty insistent about this standard.
They are, and for good reason. Twilio's glossary entry on E dot one six four explicitly states that the standard is used not just for voice call routing but for SMS, MMS, and VoIP interoperability. Any system that needs to uniquely identify a phone number globally — whether it's sending a text message, routing a voice-over-IP call, or delivering a multimedia message — has to use E dot one six four as the canonical identifier. It's the primary key for the global phone network.
Which means formatting your number correctly once unlocks multiple channels. Same E dot one six four string works for a tel link, a WhatsApp click-to-chat, an SMS gateway, a Twilio programmable voice setup.
That's the multiplier effect. A restaurant that formats its number as plus one two one two five five five one two three four can use that exact string in the website's tel link, in the WhatsApp button, in the SMS reservation reminder system, and in the VoIP backend. One canonical number, everywhere. Get it wrong once, and you've broken it everywhere.
The silent failure mode again. Nothing errors out — the message just doesn't arrive, the call doesn't connect, and the business assumes it was a slow Tuesday.
We've established the technical mechanism and the silent-failure problem. But let's put numbers on what "silent failure" actually costs. UX researchers have been studying friction in mobile interactions for years, and the pattern is remarkably consistent. Every additional step you insert between intent and action loses people. Copy the number — you lose some. Switch to the phone app — you lose more. Paste and dial — you lose more still. By the time you're through a four-step manual process, studies suggest you've shed twenty to thirty percent of potential callers at each step.
Which compounds fast. If you lose a quarter at each of four steps, you're not keeping seventy-five percent — you're keeping about thirty-two percent.
And that's before we account for the people who see a non-clickable number and just don't bother starting. They assume the business doesn't want the call badly enough to make it easy. The fix is one HTML attribute.
Walk me through the implementation. I'm a small business owner, I've got a WordPress site, what do I actually do?
The anchor tag is the whole thing. You wrap your displayed number in an A tag with an href that starts with "tel colon" followed by the E dot one six four number — clean, no formatting characters. So the visible text says "zero two zero seven nine four six zero one two three" with whatever spacing makes sense for human eyes, and the href says tel colon plus forty-four twenty seven nine four six zero one two three. That's it. On mobile, that number is now one tap away from a phone call.
If I've got customers in multiple countries?
Then you need a small layer of logic. The simplest approach is geolocation — you check the visitor's IP, determine their country, and display the number formatted for that region with the correct E dot one six four in the link. A UK visitor sees zero two zero seven nine four six zero one two three with a plus forty-four link. A US visitor sees plus forty-four twenty seven nine four six zero one two three with the same link underneath. More sophisticated setups use a country selector dropdown, but even a basic IP lookup covers ninety percent of cases.
What about the extensions you mentioned earlier? The semicolon ext equals thing.
That's where this gets useful for businesses with phone trees. You can encode the extension directly into the link so the customer doesn't have to listen to the menu and press buttons. tel colon plus one two one two five five five one two three four semicolon ext equals one zero one dials the main number, waits for the connection, then sends extension one zero one. For DTMF tones — which is what those "press one for sales" systems use — you can use the p parameter for a pause. tel colon plus one two three four five six seven eight nine zero semicolon p equals one pauses for one second, then dials one. You can chain them for multi-level menus.
I could theoretically link directly to "press two for billing" and skip the preamble.
Whether you should depends on how stable the company's phone tree is. If they reshuffle the menu, your link now routes to the wrong department. But for a small business with a simple extension setup — the owner's direct line, the reservations desk — it's a genuine quality-of-life improvement.
What are the common ways people mess this up?
Three big ones. First, leaving formatting characters in the href — spaces, dashes, parentheses. The spec says strip them, and while some mobile browsers are forgiving, others aren't. You'll never know which browser your customer is using. Second, using the domestic format with the leading zero in the link. A UK number with a leading zero in the tel URI will fail for anyone dialing from outside the UK. And third, the multi-country problem — displaying a single domestic number with no country code at all, which works fine for local visitors and is completely useless for everyone else.
All three of those fail silently. The link just doesn't connect.
That's the recurring theme. There's no error message, no bounce notification, no analytics event that says "you lost a lead here." The business owner checks the website, sees the number displayed correctly, and assumes everything works.
The WhatsApp angle you mentioned earlier — that's the same E dot one six four string?
Same exact format. WhatsApp's click-to-chat links use wa dot me slash followed by the full E dot one six four number — no plus sign in some implementations, with it in others, but the number itself is identical. SMS gateways use it. Twilio's programmable voice API uses it. Any system that needs to address a specific phone number on the global network converges on E dot one six four as the canonical format. Format it once, use it everywhere.
The business that fixes this for their website accidentally fixes it for WhatsApp, for SMS reminders, for their VoIP system.
That's the multiplier. And it works in reverse too — if your SMS provider already has your number in E dot one six four, you can drop that exact string into your website's tel link and it just works. No conversion, no cleanup.
There's an accessibility argument here too, isn't there?
There is, and it's one that doesn't get enough attention. For users with motor disabilities — anything from Parkinson's to cerebral palsy to arthritis — the four-step copy-switch-paste-dial process isn't just inconvenient, it's sometimes physically impossible. A tappable link that opens the dialer directly is the difference between being able to contact a business and being locked out entirely. The WCAG two point one guidelines explicitly recommend making phone numbers clickable for exactly this reason.
It's not just a conversion optimization thing. It's an access thing.
Those two things align more often than people think. Making something accessible tends to make it better for everyone. The curb-cut effect — ramps at intersections were designed for wheelchair users, but they also help people with strollers, delivery carts, luggage. A clickable phone number helps someone with motor disabilities, and it also helps someone carrying groceries in one hand who just wants to tap and talk.
Which makes it even stranger that this isn't standard practice. Every website builder, every CMS, every e-commerce platform should be handling this automatically by now.
Shopify auto-detects phone numbers and wraps them in tel links. Squarespace has a click-to-call block. But the vast majority of small business sites — the local plumber, the corner restaurant, the independent dentist — they're on generic WordPress themes or static sites where the number was typed into a text field five years ago and never touched again.
They're losing calls every day and have no idea.
That's the part that keeps me up at night. Well, not literally.
Let's make this practical. If you're listening and you run a website — or you built one for someone else — here's the four-step audit you can do right now.
Step one: find every phone number on your site. Header, footer, contact page, about page, blog sidebar. Are they plain text or are they wrapped in a tel link? Most of them won't be. Step two: for each number, strip the leading zero if your country uses one, prepend the country code with a plus sign. That London number becomes plus forty-four twenty seven nine four six zero one two three. Step three: wrap it in an anchor tag with tel colon and that clean E dot one six four string — no spaces, no dashes, no parentheses. Step four: if you serve customers in multiple countries, add a small geolocation script or a country selector so visitors see the number formatted for their region with the correct international link underneath.
Step four is the one most people skip because it sounds complicated.
It's not, though. There are tools that handle the heavy lifting. Google's libphonenumber library — open source, actively maintained — can parse, validate, and format phone numbers in E dot one six four across more than two hundred countries. You give it a string like "zero two zero seven nine four six zero one two three" and a country code, and it returns the canonical plus forty-four version, tells you whether the number is valid, and even identifies what kind of number it is — mobile, landline, toll-free.
You don't have to write your own regex and hope you didn't accidentally nuke someone's internal zero.
You absolutely should not write your own regex. Phone number parsing is one of those problems that looks trivial and turns out to be a bottomless pit of edge cases. libphonenumber has been handling those edge cases for over a decade. Twilio's Lookup API does something similar — you send it a number, it returns the validated E dot one six four format along with carrier information and line type. It's a paid service, but for businesses that rely on phone calls, the cost is negligible compared to the leads you're losing.
The whole fix — audit, convert, wrap, deploy — what are we talking, five minutes per number?
If you know what you're doing, less. The hard part isn't the implementation, it's knowing the implementation exists. That's what makes E dot one six four a quiet standard. It's been doing its job for decades, invisibly, while millions of websites just... didn't get the memo.
Which is the broader point Daniel's really getting at. This isn't a complicated problem. It's an unknown problem. The developers who know about E dot one six four assume everyone else does. The developers who don't never think to ask.
The businesses in the middle lose money every day without ever finding out why. A five-minute fix with measurable ROI — fewer abandoned calls, more reservations, more bookings — and the only barrier was awareness.
One question I keep coming back to, though — what happens when the phone number stops being the primary identity? RCS is rolling out now, Google's been pushing it hard, and it's designed to replace SMS with something more like a messaging app. Read receipts, typing indicators, group chat that doesn't fall apart.
RCS still uses phone numbers as the identifier.
It does, for now. Your RCS identity is your phone number in E dot one six four format. But the GSMA, which manages the RCS standard, has been talking about moving toward a more flexible identity model — something closer to email addresses or usernames, the way WhatsApp and Signal already let you create a profile that isn't strictly tied to the SIM card.
The question is whether E dot one six four remains the primary key, or becomes one of several.
And there's a real tension here. Phone numbers are globally unique, they're already assigned, and the routing infrastructure is built on them. But they're also tied to carriers, to SIM cards, to geographic regions in ways that feel increasingly outdated. If RCS eventually lets me message you at "herman at poppleberry dot com" instead of plus nine seven two whatever, does E dot one six four become a legacy fallback?
My instinct is that it sticks around longer than anyone expects. The phone number has survived email, instant messaging, VoIP, video calling — every new communication layer just stacks on top of it.
The cockroach of digital identity.
I was going to say the foundation, but sure, the cockroach works. The point is, even if RCS eventually supports email-style addressing, the phone network underneath still routes on E dot one six four. And that network isn't going anywhere.
Which brings us back to the immediate thing. Whatever the future looks like, right now, today, there are businesses losing calls because their website treats a phone number like decorative text. And the fix is one of the simplest things a developer can do.
The best standards are the ones you never notice until they're missing. E dot one six four is invisible infrastructure — it's what makes "just dial the number" work across borders, across carriers, across decades of accumulated technology. Don't let your website be the place where that infrastructure breaks.
Now: Hilbert's daily fun fact.
Hilbert: In the early Renaissance, beekeepers in Florence observed that their bees performed different waggle-dance dialects depending on whether the hive had been sourced from Liguria or Tuscany — effectively discovering that bee communication has regional accents, and inadvertently launching a minor trade war over whose bees were better at finding clover.
A Renaissance bee-dialect trade war.
I have so many questions and I'm accepting that none of them will be answered.
Thanks to our producer Hilbert Flumingtop for that. This has been My Weird Prompts. If you want to send us a question like Daniel did, email the show at show at my weird prompts dot com.
Or just put it in a tel link and we'll call you back.
