How to Add a Per-User Context Menu Item for .url Internet Shortcut Files in Windows via the HKCU Registry

Learn to add a per-user context menu verb for Windows .url Internet Shortcut files via the HKCU registry, with notes on HKCR, UserChoice, browser associations.

Adding a per-user context menu item in Windows is usually straightforward: write a verb under HKCU and let the shell pick it up. It works reliably for generic files, folders, and .lnk shortcuts. Internet Shortcuts (.url), however, are wired differently and that’s where things tend to stall.

Problem in code

The typical pattern for registering a context menu verb under the current user looks like this:

import winreg as wreg
key_path = r"SOFTWARE\Classes\*\shell\NewItem"
with wreg.CreateKey(wreg.HKEY_CURRENT_USER, key_path) as root_handle:
    wreg.SetValueEx(root_handle, 'MUIVerb', 0, wreg.REG_SZ, 'New Item')
    with wreg.CreateKey(root_handle, 'command') as action_key:
        wreg.SetValue(action_key, '', wreg.REG_SZ, r'"C:\...\app.exe" "%1"')

With this structure, assigning SOFTWARE\Classes\*\shell\NewItem targets “all files”, SOFTWARE\Classes\Directory\shell\NewItem targets folders, and SOFTWARE\Classes\lnkfile\shell\NewItem targets .lnk shortcuts. Attempting to adapt the same approach to Internet Shortcuts via SOFTWARE\Classes\InternetShortcut\shell or SOFTWARE\Classes\.url\shell\NewItem does not yield the expected result.

What’s really going on

Windows keeps the systemwide catalog of file type registrations in HKEY_CLASSES_ROOT. HKCU\Software\Classes overlays that catalog with user-specific overrides. Reading is merged; writing to HKCR is restricted without administrative privileges, whereas HKCU\Software\Classes is writable per user.

For .url specifically, the systemwide registration exists, while a user-scoped equivalent is often absent. That explains why adding entries only under HKCU might seem to have no effect. The class name of interest here is InternetShortcut. Another practical detail is that the effective association can be controlled by a ProgId stored under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.url\UserChoice. That value can be something like IE.AssocFile.URL, ChromeHTML, FirefoxURL, OperaHTML and so on, which influences how .url is handled.

There is also a behavioral nuance: for other file types, additional handlers tend to surface in the “Open with” UI. Internet Shortcuts do not show “Open with” by default, and enabling it requires administrative rights, as documented here: https://www.elevenforum.com/t/add-or-remove-open-with-context-menu-to-url-files-in-windows-11.11958/.

Solution direction

The actionable path is to place a per-user override for the class named InternetShortcut under HKCU\Software\Classes. That is the user layer that complements or overrides HKEY_CLASSES_ROOT. Whether you also need to override the uppercase .URL extension per user, or replicate the systemwide InternetShortcut subkeys before extending them, or simply add the verb under a newly created class key, can vary. The base class is InternetShortcut; the actual subtrees under HKEY_CLASSES_ROOT\InternetShortcut can differ between Windows versions and according to the configured browser, so reading what your system currently has with regedit.exe is the safe first step.

User-scoped write example

The following snippet places a verb under the per-user class key InternetShortcut. It uses the same values and structure as the working pattern for other types, but points at the class relevant to .url:

import winreg as wreg
user_class_path = r"SOFTWARE\Classes\InternetShortcut\shell\NewItem"
with wreg.CreateKey(wreg.HKEY_CURRENT_USER, user_class_path) as cls_key:
    wreg.SetValueEx(cls_key, 'MUIVerb', 0, wreg.REG_SZ, 'New Item')
    with wreg.CreateKey(cls_key, 'command') as cmd_node:
        wreg.SetValue(cmd_node, '', wreg.REG_SZ, r'"C:\...\app.exe" "%1"')

If the effective handler for .url on your machine is governed by a ProgId under ...\FileExts\.url\UserChoice, be aware that this can affect how your new verb is surfaced. The systemwide reference for what the InternetShortcut class looks like can be inspected at HKEY_CLASSES_ROOT\InternetShortcut, and values there may differ across systems.

Why this matters

Context menu integration for .url files sits at the intersection of systemwide classes, user-level overrides, and the current browser association. Writing only to HKCU is a good practice for per-user installs, but for Internet Shortcuts it is easy to target the wrong entry point or expect UI that is not present by default. Understanding that HKCU\Software\Classes is an overlay for HKCR clarifies why writes to one hive may not reflect immediately, and why permissions can block changes under HKCR.

Takeaways

Identify the relevant class as InternetShortcut and place your custom verb under HKCU\Software\Classes to avoid requiring administrative rights. Verify what the systemwide class contains in HKEY_CLASSES_ROOT and remember that browser configuration and OS version can change those details. If the association for .url is steered by a ProgId in the user’s ...\UserChoice, that also shapes the outcome. Where the “Open with” route would normally reveal handlers, .url behaves differently and enabling that UI requires admin-level changes.

With these constraints in view, you can add a per-user verb in the right place and test on the target environment to confirm the expected behavior.