Web Apps Can Now Own Protocol Handling

With Chrome 13, the browser finally ships navigator.registerProtocolHandler. The API lets a web application present itself to the user as a potential destination for specific URL schemes. A common use case: letting users route mailto links to a web-based email client rather than the desktop default.

Registration takes the desired scheme and the app's endpoint:

navigator.registerProtocolHandler(
    'web+mystuff', 'http://example.com/rph?q=%s', 'My App');

The first argument names the protocol. The second is the URL template for your handler, which must include %s as the payload placeholder. The origin of that template must match the page calling the API—a third-party service cannot register itself from your domain.

After the user grants permission, the scheme works beyond the registering page. Links on other sites, for instance, can invoke the handler:

<a href="web+mystuff:some+data">Open in "My App"</a>

Activating such a link triggers a GET request to the handler URL, encoding the raw content after the scheme. For the example above, the request lands on http://example.com/rph?q=web%2Bmystuff%3A:some%20data. The app must subsequently read the q parameter and peel away the protocol prefix to recover the actual data.

Scheme Restrictions and Firefox Compatibility

Firefox has supported this API since version 3, but Chrome's implementation diverges on naming rules. Custom protocols in Chrome must carry a web+ prefix—hence web+mystuff. A few standard schemes, listed below, are exceptions and can be used without the prefix:

  • mailto
  • mms
  • nntp
  • rtsp
  • webcal

For deeper technical details, see the MDN documentation.