Windows 11 users are seeing a puzzling and persistent context‑menu entry —
“Edit in Notepad” — appear for virtually every file type in File Explorer, from plain text to JPEGs and even .exe binaries, and a simple registry tweak can hide it; the fix works, but it also exposes broader design and maintenance issues with the modern Windows 11 File Explorer context menu and how system apps register themselves.
Background
Since Windows 11's launch, Microsoft redesigned File Explorer’s right‑click menu to be more compact and modern. That change split the classic long list into a streamlined set of common commands (Cut, Copy, Paste, etc. with an option to open the legacy, fuller menu via “Show more options.” The goal was cleaner visuals and fewer distracting items, but over time third‑party apps and newly modernized Microsoft apps began adding their own entries — sometimes redundantly — and the new model has generated complaints about both clutter and missing context sensitivity. At the same time, Notepad — the long‑standing simple text editor — has been upgraded repeatedly: tabs, dark mode, spellcheck/autocorrect, autosave/session restore, and even Copilot integration have all been added to the app in recent updates. Those improvements are welcome to many, but they appear to have changed how Notepad registers itself with the shell, and that change is at the root of the current “Edit in Notepad” problem.
What’s happening: “Edit in Notepad” on every file
- The symptom is straightforward: when you right‑click virtually any file in File Explorer — images, videos, ISOs, executable files — a top‑level entry labeled Edit in Notepad appears alongside other app actions. Clicking it opens Notepad and displays the file’s raw bytes interpreted as text. That behavior is the result of opening a binary as if it were text, which yields garbled characters.
- Why it appears for everything: community analysis and multiple how‑to sites point to the way the modern Notepad app registers a shell extension or declares itself as a general‑purpose text editor/handler. Instead of registering only for explicit text file extensions (.txt, .log, .cfg, .bat, .ps1, etc., Notepad now identifies itself in a manner the shell interprets as applicable to any file that might contain text, and File Explorer therefore shows the Notepad action more broadly than before. This is the most plausible technical explanation available today, but Microsoft has not published an explicit changelog line saying “we registered Notepad this way” — the claim is supported by community investigations and multiple independent guides that document the visible result and the registry workaround. Treat the root‑cause explanation as a well supported community inference rather than a Microsoft‑issued admission.
- Practical consequence: clicking “Edit in Notepad” on a binary file typically does no damage by itself, but saving a binary after opening it as text will corrupt the file. Displaying executable contents in a text editor can also be confusing and looks alarming to less technical users.
The verified registry workaround (how to remove “Edit in Notepad”)
If you want to remove
Edit in Notepad from the File Explorer context menu, you can do so by creating a Blocked shell‑extension entry in the registry. This approach is widely documented by major Windows how‑to outlets and community forums and is reversible. The steps here are the same as those listed by multiple independent sources and have been tested by the Windows community. Important preparatory notes:
- Back up your registry and create a System Restore point before proceeding. Mistakes in Registry Editor can render apps or the system unstable.
- You can apply the setting for the current user (HKCU) or for all users (HKLM) — the examples below show both options.
- After making the change either reboot or restart the Explorer process for changes to take effect.
- Open Registry Editor as an administrator: press Windows, type regedit, right‑click Registry Editor → Run as administrator.
- Navigate to:
- For current user only:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions
- To apply system‑wide (requires admin):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions
- If the key named Blocked does not exist under Shell Extensions, create it:
- Right‑click Shell Extensions → New → Key → name it Blocked.
- Under the Blocked key, create a new String Value (REG_SZ) and name it exactly as the GUID for the extension you want to hide.
The GUIDs commonly used to block specific modern File Explorer actions are documented across multiple reputable guides:
- To remove Edit in Notepad (current user): create a String Value named
{CA6CC9F1-867A-481E-951E-A28C5E4F01EA}.
- To remove Ask Copilot (Copilot right‑click entry): create
{CB3B0003-8088-4EDE-8769-8B354AB2FF8C}.
- To remove Edit with Clipchamp: create
{8BCF599D-B158-450F-B4C2-430932F2AF2F}
(some sources list an alternate GUID {8AB635F8-9A67-4698-AB99-784AD929F3B4} for Clipchamp; GUIDs for rapidly evolving UWP apps can differ by app version or regional packaging — if the first GUID doesn't work, adding the alternate one has been reported to help). If a GUID you add has no effect, confirm you used the correct hive (HKCU vs HKLM).
- To remove Edit with Paint: create
{2430F218-B743-4FD6-97BF-5C76541B4AE9}.
- Close Registry Editor and restart your PC or restart the Explorer process (Task Manager → Windows Explorer → Restart).
- Right‑click a file to confirm the entry is gone. If the top‑level modern menu is still present, the suppressed items will often still appear under Show more options; blocking the GUID removes the modern action from the first level.
Example .reg snippet for current user removal (replace quotes with none when saving to .reg file):
- Add a REG file with:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked]
"{CA6CC9F1-867A-481E-951E-A28C5E4F01EA}"=""
Creating the same value under HKLM will enforce it system‑wide (administrator rights required).
Confirmed behavior and limits of the fix
- Blocking the GUID removes the modern top‑level Edit in Notepad entry for files in the compact context menu in the normal File Explorer view. However, the legacy extended menu (“Show more options”) may still contain the entry — Microsoft’s modern menu and the legacy menu are separate render paths and the Blocked key mainly impacts the modern shell extension list. Consider this a cosmetic and UX relief rather than a universal programmatic block.
- Blocking the GUID does not uninstall Notepad or disable its features — it only prevents the shell from exposing that particular extension entry. Likewise, blocking Copilot’s GUID removes the right‑click entry but does not remove Copilot itself from Windows; the app remains installed and usable through other UI surfaces. That distinction is important for administrators who want to reduce clutter without removing functionality.
- Some community documentation lists alternate GUID mappings, and there’s occasional inconsistency across guides. If a given GUID has no effect, verify you created the Blocked value in the correct hive (HKCU vs HKLM) and that you typed the GUID exactly. When in doubt, try both hives and restart Explorer.
Risks, warnings, and best practices
- Registry edits are risky. Always export the key you intend to change and create a System Restore point before making changes. If you make a mistake, you can import the exported registry file or roll back via System Restore.
- Saving binary files through Notepad will corrupt them. Opening an .exe, .dll, .iso or image file in Notepad is harmless for viewing, but editing and saving will overwrite the binary, destroying the file. Do not save unless you explicitly intended to convert a file to text and accept file loss.
- Blocking shell extensions can hide useful functions. Some apps expose multiple verbs or small helper actions in the right‑click menu; blocking a GUID removes that verb but may also hide related functionality. Test after making changes to ensure no critical workflows are broken.
- Enterprise policies exist but aren’t a panacea. Windows has group policies and mechanisms around shell extension security (for example, EnforceShellExtensionSecurity), but community reporting and Microsoft Q&A threads indicate those controls do not always behave as expected across Windows 10/11 versions and shell extension models. Admins should test policies in their environments rather than assuming universal effect.
Alternatives to editing the registry
- Use “Open with” or change default file associations: for text files you can still double‑click to open in Notepad, or use “Open with” → choose another app. This avoids registry edits entirely and keeps the context menu intact.
- Disable Notepad app execution alias or revert to classic Notepad: advanced users who prefer the old, classic notepad.exe behavior can disable any “app execution alias” for Notepad in Settings → Apps → Advanced app settings → App execution aliases, or use community tools to redirect modern Notepad calls to the classic binary. A community mod and utilities exist to intercept modern Notepad and invoke a classic editor instead — this is a more invasive tweak and should be used only by experienced users.
- Use shell‑extension managers: utilities like ShellExView (and similar community tools) let you view and disable third‑party shell extensions. Those tools let you selectively disable context‑menu handlers from the registry without hand‑editing GUIDs, but they require careful use and are best applied by experienced users.
Why Microsoft’s design choices matter — a critical look
Windows 11’s compact context menu was intended to reduce visual noise and modernize the shell. The changes were well intentioned: fewer immediately visible choices, grouping of related actions, and separation between essential shell verbs and app‑provided commands. However, practice diverged from intent:
- The new model relies on apps to register suitable, context‑aware actions. When an app declares itself too broadly (as Notepad appears to do) it creates mismatches between item relevance and display, leading to misleading menu entries such as “Edit in Notepad” on a .dll or .png. The result is an erosion of user trust in the menu’s contextuality.
- The modern menu still defers to the legacy “Show more options” menu for complete functionality, forcing a two‑click workflow for power users. Some community members prefer the old single‑click full menu or demand easier editing controls; Microsoft has acknowledged this and is experimenting with a new “Split Context Menu” API to let developers present primary and secondary actions more intelligently. The Split Context Menu is promising: it lets a menu item act as a default action on the left and a flyout of related secondary options on the right, which could reduce redundancy and keep similar items grouped. That work is in progress and currently available as a WinUI control for developers to prototype against.
- Microsoft’s moving parts — WinUI, app packaging via the Store, and Shell extension registration — are evolving quickly. As system apps like Notepad move to Store/updatable models, the shell’s expectations and the app registration semantics must be reconciled. When those pieces get out of sync, the user sees issues like overbroad context‑menu entries. Community fixes (registry Blocked entries) are effective short‑term but are not long‑term solutions for maintainability or discoverability, and they place the burden on users or administrators rather than on the platform to enforce sensible defaults.
What users and administrators should do now
- If the visible annoyance affects you and you want a quick, reversible relief, use the Blocked GUID registry tweak. Back up first, then add the GUID {CA6CC9F1-867A-481E-951E-A28C5E4F01EA} under HKCU or HKLM as described above to hide Edit in Notepad.
- If you administer machines, consider a controlled rollout: test the registry changes on a pilot group to ensure no business workflows break, and document the change so you can revert it centrally if needed.
- If you prefer not to touch the registry, use “Open with” to select preferred editors, and avoid clicking “Edit in Notepad” on non‑text files.
- Monitor Windows Insider and official Windows App SDK/WinUI communications. Microsoft has publicly discussed improvements to the context menu via the WinUI project and the Split Context Menu control; these platform changes are likely to be the permanent fix rather than per‑GUID registry blocks.
Final analysis: short‑term fix, long‑term design question
The “Edit in Notepad” issue is symptomatic of a larger tension: modernizing Windows UI and shifting apps to the Store allows more frequent improvements, but it also changes how those apps advertise functionality to the shell. The immediate problem has an effective, reversible registry solution that many reputable guides and community posts have reproduced, and administrators can deploy it where necessary. Longer‑term, the real fix should come from coordinated platform changes: better app registration semantics so editors don’t advertise themselves for clearly non‑text file types, and a File Explorer context menu model that both reduces clutter and preserves single‑click access to genuinely relevant commands. Microsoft’s work on WinUI and the Split Context Menu is a constructive sign that the company recognizes the problem and is building API‑level solutions for developers; until that work ships broadly, expect the registry GUID block trick to remain the pragmatic, community‑endorsed workaround.
Windows users who apply the registry changes should verify their environment afterward, keep an export of any modified registry keys, and be mindful not to save binary files opened in Notepad. The registry workaround is effective and reversible, but it is a stopgap — the ideal outcome will be a File Explorer that is both clean and truly contextual, without users needing to become their own UI maintainers.
Source: Windows Latest
Windows 11 issue shows "Edit in Notepad" for all file types, including .exe and images