A link does not always lead to another webpage. A mailto: link opens a composer. A webcal: link can hand a calendar feed to an application. The browser must decide which product receives that request, and websites can ask to join the list through URL protocol handlers.
The capability makes web apps more useful, but it changes the destination of a click. Browsers therefore restrict which schemes a site may claim, require secure and same-origin handler URLs, and leave the final choice to the user agent.
URL protocol handlers route special links to web apps
The navigator.registerProtocolHandler() method lets a website declare that it can handle a particular URL scheme. Webmail is the familiar example: a mail service can register for mailto:, allowing email-address links to open its web composer.
The registration includes a template URL containing %s. When the handler is used, the browser replaces that placeholder with the escaped link and navigates to the handler page. The receiving app can then interpret the value and prepare the relevant task.
This is routing, not silent execution. The link moves into a chosen web application, which still operates inside ordinary browser security boundaries. The protocol handler does not give that site control of unrelated applications or schemes.
Browsers limit which schemes can be claimed
A website cannot register itself for foundational browser schemes such as https: or about:. The API permits a defined set of schemes—including mailto, tel, sms, webcal, matrix, and xmpp—plus custom names beginning with web+.
Custom schemes must use lowercase ASCII letters after that prefix. A product could define something like web+notes: for links understood by its own ecosystem, while the prefix helps distinguish web-declared protocols from operating-system and browser internals.
The handler page itself must use HTTPS and share the origin of the page requesting registration. These requirements stop one site from presenting a handler that silently routes special links through an unrelated domain.
User choice stays between the link and the app
The WHATWG HTML standard gives browsers flexibility in how they present registration. A browser may prompt immediately, save the option until a relevant link is clicked, offer a shortlist of handlers, or let the user cancel.
That flexibility matters because choosing a handler can become a durable preference. Once webmail is selected for mailto:, email links across many websites may start opening there. A convenient decision on one page can influence future clicks elsewhere.
A site should ask only after its role is clear. A mail application can explain why it handles email links. A random landing page has no convincing reason to make the same request.
The receiving URL may contain sensitive context
Special-purpose links can include more than a destination. A mailto: URL may carry a recipient, subject, or draft body. A calendar link may identify a feed. A custom protocol can encode an object, room, or account inside its path.
When a handler is activated, the escaped original URL is inserted into the registered template. That means the chosen web app receives the link's contents. Review unfamiliar links before opening them, especially when the visible text hides a long or unusual destination.
Developers should parse the incoming value defensively. Treat it as untrusted input, reject malformed data, avoid reflecting it into HTML, and never trigger a consequential action merely because a URL arrived. The handler should open a review screen, not send a message or join a meeting without another deliberate step.
Protocol handling differs from ordinary link navigation
An HTTPS link already names both a destination and an origin. A protocol link names a type of task, then relies on browser or operating-system preferences to choose the handler. Two people can click the same mailto: link and arrive in different applications.
This indirection is useful. It preserves choice between a desktop client, an installed web app, and another compatible service. It also means websites should not assume which product will open or whether any handler is configured.
Our guide to pop-ups and redirects explains a related boundary: browsers look for user activation before allowing pages to create new navigation contexts. Protocol handlers deal with a different mechanism, but the same principle applies—one clear action should produce one understandable transition.
How to evaluate a handler request
First, confirm that the site already performs the task named by the scheme. A calendar product handling calendar subscriptions is coherent. A content site asking to handle telephone or messaging links is not.
Second, understand whether the browser is adding an option or changing a default. Interface language varies. If the choice will apply to future links, make sure the service is one you intend to keep using.
Third, test with a harmless link. Confirm that the handler opens a review or compose screen and preserves the information you expect. It should not complete an external action automatically.
Finally, know where to reverse the choice. Browsers and operating systems provide default-app or protocol-handler settings, though the location differs. Remove stale registrations when an app is abandoned.
Web integration should remain reversible
Protocol handlers let web apps participate in workflows once reserved for installed desktop software. They can make email, calls, calendars, and specialized links feel direct without forcing one vendor on every user.
The value comes from mediation. The site declares a capability, the browser checks its constraints, and the person chooses where the link goes. When that choice is visible and reversible, deeper integration does not have to mean less control.
For another example of web apps entering operating-system surfaces, read our guide to the File Handling API. It applies similar ideas to selected documents rather than special-purpose links.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.