So I stumbled across a weird Windows quirk the other day that I thought I’d share. Create a new folder on your desktop and name it “notepad” (without quotes). Then open Internet Explorer (yes, the old one, but it still works on older systems) and right-click a web page to view the source. Instead of opening Notepad, it opens that folder you just created!
I first saw this on a vintage computing forum and had to try it myself. It actually works! The discussion there was split between thinking it’s an OS error, an IE programming oversight, or an intentional Easter egg. I’m leaning towards the last one because how could the shell confuse a folder with notepad.exe? It’s like IE calls the shell command “Edit” on the HTML file, and the shell somehow resolves to the folder first because it’s named “notepad” and sits on the desktop.
This got me thinking about all those hidden gems programmers leave behind. Anyone remember the classic Windows 98 screensaver Easter egg? Go to the screensaver tab, select the “Marquee” screensaver (where you can type your name), and type “Volcano” instead. It lists all the volcanoes in the world. Cool stuff.
But here’s the darker side: couldn’t this be exploited for malware? If you can trick the OS into running a folder instead of an executable, imagine crafting a malicious folder that does something else. Of course, modern Windows has protections, but back in the XP days it might have been a vector.
What do you think? Was this a deliberate backdoor by Microsoft’s IE team (like switch said, maybe to tweak features), or just a sloppy piece of code that happened to work in our favor?
Topic Summary: Analyzing the Notepad folder trick as a shell name resolution priority issue rather than an Easter egg, with modern OS security rendering it obsolete; cultural shift in software development away from hidden features.
---
title: Notepad Folder Trick
---
flowchart TD
A["Create folder"]
B["Rename to 'Notepad'"]
C{"Special behavior?"}
D["Easter egg"]
E["Bug"]
A --> B --> C
C -->|Yes| D
C -->|No| E
That’s a golden find! I’ve seen this before and I’m pretty sure it’s a deliberate Easter egg, not a bug. Think about it: the “View Source” action just calls the shell’s “Edit” verb on the HTML file. Normally that verb is associated with Notepad.exe via the registry. But if there’s a folder named “notepad” on the desktop, the shell might resolve the name before the file association, due to how the path lookup works.
This is actually a documented behavior in older Windows versions—the shell searches the current directory and desktop for the executable name before falling back to the PATH. So if you create a folder with the same name as a system tool, it gets priority.
But I’m with you on the Easter egg theory. I used to put backdoors in my own software as a kid—just harmless stuff like showing a secret message when you press a certain key combination. The IE team probably had their fun too. There’s a whole culture of Easter eggs in Microsoft products, like the Windows 7 “GodMode” folder or the hidden pinball game in Windows XP.
As for the security implications: yes, it’s a vector, but only local. You’d need physical access or a way to drop a folder on the desktop. Still, it’s a neat reminder that even big software has its quirks.
I’ve encountered this trick before and I always explain it as a simple file association priority issue. When you right-click and choose “View Source,” IE shoots off a command to the shell to open the HTML file with the default text editor—typically Notepad. But if the shell finds an object named “notepad” on the desktop first (like a folder), it’ll try to open that instead.
This isn’t a bug per se; it’s a consequence of how the Windows shell resolves names. It’s the same reason why creating a shortcut or folder with the same name as an executable in the same directory can cause confusion.
Now, regarding the security angle: modern Windows (starting with Vista) has User Account Control and more stringent file system protections. In Windows 10/11, even if you replicate this, the shell will likely ignore a folder named “notepad” because it’s not a valid executable. But back in the 9x/XP days, it was fair game.
Fun fact: there are similar Easter eggs in other Microsoft products. The famous “Do a barrel roll” in search engines comes to mind, but that’s a different story. I’d recommend trying this in a virtual machine if you want to see it in action without risking your main system.
After reading through the discussion, I think the consensus leans correctly toward this being a shell name resolution quirk rather than a deliberate Easter egg, though the line can blur. The Windows shell’s search order prioritizes the current directory and desktop over system paths, so a folder named “notepad” intercepts the call before the actual executable is found. This was indeed exploitable on older systems like Windows 98 and XP, but as noted, modern Windows (Vista onward) introduced changes like file system redirection and mandatory integrity levels that prevent such tricks from working in practice.
What’s interesting to me is the cultural context. Back in the 1990s and early 2000s, Microsoft engineers famously hid playful Easter eggs in products like Office and Windows itself (the 3D Maze screensaver in Windows 95, anyone?). But today’s software development landscape is vastly different. Agile methodologies, continuous integration, and strict code review processes make it nearly impossible to sneak in undocumented behaviors without detection. Security audits and compliance requirements (e.g., FIPS 140-2) further discourage such practices. The “Volcano” screensaver trick is a relic; modern screensavers are rarely used, and Windows 11 doesn’t even include the classic ones.
This shift reflects a broader industry move toward transparency and reliability. While some developers still hide “konami code” commands in web apps or video games, the era of OS-level Easter eggs is largely over. The Notepad folder trick serves as a nostalgic reminder of a time when software felt more whimsical and less locked down. It also highlights how seemingly minor design decisions (like name resolution order) can have unintended consequences. In the end, it’s not a bug or an intentional gift – it’s an artifact of simpler programming practices that have since been patched out of existence.
