I can get my web app to have Chrome register a custom "web+" protocol handler such that it shows up under Settings->(Advanced)->Privacy->Content Settings->Handlers->Manage Handlers.

However, it shows the site as "none" and although my site shows up in the pull-down, when I opt for my site in that pull-down, Windows gives me a message that "No apps are installed to open this type of link (web+mycustomscheme)...Look for an app in the Store" and the clicking off of the Windows message leads back to the pull-down showing "none" (and clicking on links in my custom scheme do not work).

How do I get it to accept my site as a handler?

This works fine in Firefox, btw.

  • The + symbol looks suspicious, check if webplus works. If it does, then it's just how Chrome works and there's nothing you can do to change it.
    – gronostaj
    Commented Jun 13, 2015 at 8:45
  • Chrome is supposed to require web+ for custom protocols. This had worked earlier. I think the issue is probably some interaction problem with Windows. Commented Jun 13, 2015 at 9:14

1 Answer 1


For the first issue (getting Chrome to register your app with the custom protocol), based on my recent work attempting to active external URLs of a custom protocol this is something that Chrome still does not handle very well.

The bug here (https://bugs.chromium.org/p/chromium/issues/detail?id=560809) is related to starting these protocols from the omnibox or the command line, but I also think it applies when the link is activated via javascript (window.location or creating an iframe with that src).

From what I can tell this is still an outstanding issue.

Now - On the second part (where Windows says it doesn't know how to handle the protocol and offers up the App Store). You have to register your protocol with Windows via the registry. This is as simple as adding a specially formatted key in the HKEY_CURRENT_USER\Software\Classes as described here: https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx

Note - if you follow the instructions on that page you will be registering a protocol handler for all users of that machine, and the app doing the registration will need elevation (Admin). If you use HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT, your registration will still show up under HKEY_CLASSES_ROOT but will not require admin to create, but it will only work for the current user. So - pick your poison on that.

HKEY_CLASSES_ROOT is kind of a view comprised of all the \Software\Classes from HLEY_CURRENT_USER combined with HKEY_LOCAL_MACHINE. I believe but haven't confirmed that the HKCU overrides HKLM, but if you try to create a key directly in HKEY_CLASSES_ROOT it will try to write it to HKLM, giving you an access denied unless you have elevation.

I hope this helps. Good luck.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .