Click to call is any mechanism that turns a click or tap on a web page into a live phone call. It comes in two fundamentally different architectures: the tel: link, where the visitor’s own phone places the call, and the callback bridge, where a server dials the visitor and the business as two separate call legs and joins them. The first is one line of HTML. The second is real telephony — outbound trunk capacity, a caller ID number, and a bridge — dressed up as a button.
The distinction matters because the two patterns have different costs, different failure modes, and different measurement stories. A tel: link costs nothing and works on nearly every smartphone. A callback bridge costs two outbound legs per conversation and works anywhere, including a desktop browser with no phone attached. Most “click to call” confusion comes from treating them as one feature.
Architecture one: the tel: link
On mobile, click to call is a hyperlink. The tel: URI scheme — standardized in RFC 3966 — tells the device that the link target is a telephone number rather than a web address. Tapping it hands the number to the phone’s native dialer:
<a href="tel:+18336652220">(833) 665-2220</a>The number in the href should be in E.164 format — plus sign, country code, full national number — so the link dials correctly regardless of where the visitor is or how their carrier handles local formatting. The visible anchor text can stay human-formatted.
Two properties define this architecture. First, the call is placed by the visitor’s phone, on the visitor’s carrier plan, from the visitor’s own number. No infrastructure on your side is involved until the call arrives at your inbound number like any other call. Second, the click and the call are separate events: the tap opens the dialer, but the visitor still has to press call. A tel: tap in your analytics is intent, not a connected conversation.
On a desktop browser, a tel: link either does nothing, opens a prompt asking which application should handle it, or launches a softphone or paired-device handoff if one is configured. For the average desktop visitor, it is a dead end — which is the gap the second architecture exists to fill.
Architecture two: the callback bridge
Callback-style click to call replaces the link with a small form: the visitor enters their phone number and clicks a button. A server then places two outbound calls — one leg to the visitor’s number, one leg to the business — and bridges them into a single conversation. Some implementations dial the business first so an agent is on the line before the visitor’s phone rings; others dial the visitor first or launch both legs in parallel.
The visitor’s device never places a call. Their phone simply rings, they answer, and the business is on the other end. That is why this pattern works from any browser on any device: the web layer only collects a number and triggers an API or PBX action, and the phone network does the rest.
A third variant places the call directly in the browser over WebRTC — microphone and speakers instead of a phone. It solves the same desktop problem but swaps the second call leg for an internet audio session, which makes call quality dependent on the visitor’s connection. Most business deployments stick with the callback bridge because it lands on a real phone.
What the callback pattern runs on underneath
Strip away the widget and a callback bridge is three pieces of carrier-layer plumbing.
Outbound trunk capacity. Every bridged conversation consumes two simultaneous outbound legs on a SIP trunk — one to the visitor, one to the business. That is the cost model: you pay outbound per-minute rates on both legs for the duration of the call, and your trunk needs enough concurrent-call headroom to absorb click-to-call traffic on top of normal outbound volume.
A caller ID number. The leg that rings the visitor has to display something, and that something must be a real DID provisioned to the account placing the call. This is not cosmetic. A callback from a number the carrier has verified gets signed with full STIR/SHAKEN attestation; a callback from an unregistered or borrowed number risks arriving as “Spam Likely” — at which point your click-to-call button is generating calls nobody answers.
The bridge. Something has to originate both legs and join the audio: a PBX with an originate function, a contact-center platform, or a click-to-call SaaS widget that drives one of those through an API. That orchestration layer is a software choice. The numbers, the trunk, and the call records underneath it are carrier products — SIPNEX supplies that layer with DIDs and trunking at published per-minute rates, whatever software you bridge with.
Click to call vs dynamic number insertion
Click to call and dynamic number insertion get conflated because both live in the phone number on your website. They solve opposite problems. Click to call reduces the friction of starting a call. DNI answers which marketing channel caused a call, by swapping the displayed number per visitor source so the dialed number itself carries the attribution — the full mechanics, pool sizing, and NAP rules are covered in our dynamic number insertion guide.
The two compose naturally. A DNI script rewrites tel: links along with the visible number, so a visitor from Google Ads taps a link that dials the Google Ads tracking number — the click-to-call convenience and the source attribution ride on the same tap. A callback widget can do the equivalent by stamping the visitor’s session source onto the callback request, or by using a source-specific DID as the business-side leg.
If you only remember one line: click to call is a conversion feature, DNI is a measurement feature, and both ultimately resolve to which number got dialed.
Implementing click to call on a business site
For most business sites the honest implementation is layered, not either/or.
Start with tel: links on every displayed phone number, sitewide, in E.164 form. This is free, requires no vendor, and covers the majority of visitors who are already on a phone. Make the tap target comfortably large on mobile, and fire an analytics event on the click so taps show up in reporting.
Add a callback bridge only if desktop traffic justifies it. Check your analytics first: if 80 percent of your calls-from-web intent is mobile, a tel: link already serves it. Callback widgets earn their keep on desktop-heavy B2B sites where a visitor is researching at a workstation and the alternative is “memorize this number and dial it on your phone.”
If you deploy a callback, three details separate a working install from a spam-folder one: the visitor-facing leg must present a verified DID you control, the business-side leg must land somewhere staffed (a queue or ring group, not a voicemail box), and business-hours logic must suppress the widget when nobody can answer — a callback that rings a closed office burns trust twice, once for each party it rang.
Measuring click to call: taps lie, CDRs don’t
A tel: tap is a browser event. It fires when the dialer opens — not when the call connects, not when anyone answers, and sometimes when a visitor fat-thumbs the number while scrolling. Web analytics can count taps; it cannot tell you which taps became conversations.
The ground truth lives in call detail records. Every call that actually traverses the trunk — an inbound call from a tapped tel: link, or both legs of a callback bridge — generates a CDR with the timestamp, calling and called numbers, duration, and disposition. Joining tap events against CDRs by time and dialed number turns “clicks” into answered-call counts and talk time. Per-number CDRs are the same raw material that powers call tracking and attribution reporting, which is why tracking numbers and click to call fit together so cleanly: the dialed DID identifies the source, and the CDR proves the conversation happened.
For callback bridges, the CDR story is even better — both legs are on your trunk, so you see visitor answer rates, agent pickup speed, and abandoned bridges directly in the records, no client-side inference required.
Frequently asked questions
Is a tel: link the same as click to call?
A tel: link is the simplest form of click to call, but not the only one. The tel: URI scheme (defined in RFC 3966) makes a phone number tappable: the visitor’s own device places the call through its native dialer. The broader click-to-call category also includes callback bridges — where a server dials the visitor and the business as two separate legs and joins them — and WebRTC in-browser calling. On mobile, tel: links cover most of the need; the other patterns exist mainly to make desktop visitors callable.
Does click to call work on desktop browsers?
A tel: link usually does not — on a desktop with no softphone configured, clicking it either does nothing or opens an app-picker prompt. Desktop click to call works through a callback bridge instead: the visitor types their phone number into a widget, a server places one call leg to that number and another to the business, and bridges them. The visitor’s desktop never handles audio; their phone just rings. Underneath, that pattern needs outbound SIP trunk capacity for two legs per conversation and a verified caller ID number for the visitor-facing leg.
How is click to call different from dynamic number insertion?
Click to call is a conversion mechanism — it reduces the friction of starting a call, either by making the number tappable or by calling the visitor back. Dynamic number insertion is an attribution mechanism — it swaps the displayed number per visitor source so the dialed number reveals which channel produced the call. They compose: a DNI script rewrites tel: links along with the visible number, so one tap delivers both the convenience and the attribution. The mechanics of number pools and per-source swapping are covered in our dynamic number insertion guide.
Can you track calls that come from a tel: link?
Partially from the browser, fully from the phone network. An analytics event on the link click counts taps, but a tap only means the dialer opened — it does not confirm the call was placed, connected, or answered. The reliable record is the CDR: every call that reaches your number generates a call detail record with timestamp, caller, dialed number, duration, and disposition. Pair tel: links with per-source tracking numbers and the dialed DID identifies the channel while the CDR confirms the conversation — the model behind CDR-based call tracking.
What infrastructure does callback-style click to call need?
Three layers. First, a bridge — a PBX originate function, contact-center platform, or click-to-call widget that triggers the two call legs and joins the audio. Second, outbound trunk capacity, because every bridged conversation consumes two simultaneous outbound legs billed at per-minute rates. Third, a provisioned DID to present as caller ID on the leg that rings the visitor — it must be a number your carrier has verified for STIR/SHAKEN attestation, or callbacks risk displaying as spam and going unanswered. The bridge is a software choice; the numbers, trunk, and CDRs are carrier products.
Click to call is only as good as the telephony underneath the button. SIPNEX is an FCC-licensed carrier providing the layer that makes it work: DIDs with A-level STIR/SHAKEN attestation for the numbers your visitors see, SIP trunking for the callback legs, and real-time CDRs to prove which clicks became conversations. See our per-minute rates or call (833) 665-2220.
Keep reading.
The carrier built by operators, for operators.
FCC-licensed carrier with its own STIR/SHAKEN SP certificate. Operator-owned. SIP trunks built for operators who dial at volume.