Deleting files in File Explorer is as easy as hitting the Delete key, whether you’re tidying up a project or clearing out Windows files and folders to free up disk space. However, this simple process becomes painfully slow when the folder has thousands of small files. Now imagine having to delete over 2 million logs from a server. You’re looking at a deletion process that runs for at least half an hour.

This happens because File Explorer goes through a multi-step routine around every delete: it walks the folder tree to count every file, writes a metadata record of where the files came from, and handles each item through the Windows shell while keeping other apps informed of every change. But you can skip this process entirely using PowerShell or Command Prompt.

Why File Explorer is so slow at deleting large folders

It counts everything before it deletes anything

Before deleting anything, File Explorer counts every file and adds up the total size. For a folder, that means walking the whole folder tree to find every file inside, so it can feed the progress dialog and estimate how long the job will take. Do that for 100,000 or a million files, and the scan alone can take minutes before a single file is gone.

By default, Windows doesn’t delete files right away either. It moves them to the Recycle Bin, which lives in a hidden $Recycle.Bin folder on each drive. Each item you delete gets moved in, renamed, and paired with a small metadata file that records when it was deleted and where it came from. Windows also checks the total against the Recycle Bin’s size limit to decide whether the item fits, or whether it should ask you to delete it permanently instead.

Once the counting is done, how fast the rest feels depends on where the files are going. If you send a folder to the Recycle Bin, it’s pretty quick, because Windows moves the entire folder as a single item. Permanently deleting it with Shift + Delete is a different story. File Explorer hands the job to the Windows shell, which removes each file one by one, keeps updating the progress dialog, and notifies other programs along the way. To see how much that costs, I ran a short test, and the results point straight at the permanent delete option.

The command line wastes no time

PowerShell and del finished well ahead of File Explorer

The fix is to skip File Explorer and use PowerShell’s Remove-Item command, or the del and rmdir commands in Command Prompt. Neither one counts files first, draws a progress dialog, or tells other apps about each deletion.

To test this, I built a folder that looks like a developer’s node_modules folder, the kind of folder File Explorer takes forever to delete. It has 100,000 small .js files totaling about 50MB, spread across 5,500 folders: 500 top-level package folders, each with 10 lib subfolders holding 20 files. I kept it small so that it measures the cost of handling each file rather than how fast the drive can write data. I ran everything on my HP Pavilion Gaming 15 with a Crucial MX500 SATA SSD, running Windows 11 25H2 with Microsoft Defender switched on.

I compared five methods: File Explorer’s normal delete to the Recycle Bin, File Explorer’s Shift + Delete, Command Prompt’s del /f /s /q to remove the files followed by rmdir /s /q to clear the leftover folders, PowerShell’s Remove-Item -Recurse -Force, and Robocopy, which I’ll get to in a moment.

I ran the File Explorer methods through the same Windows shell function that Explorer uses, so I could time them exactly instead of relying on a stopwatch. Each method deleted a fresh copy of the same folder, and I timed every run with PowerShell’s Measure-Command.

Here’s how they did:

Shift + Delete, the option most people reach for when they want a folder gone for good, was the slowest of the lot. It took more than twice as long as PowerShell. The Recycle Bin looks decent in third place, but only because it didn’t delete anything. When I checked the hidden $Recycle.Bin folder afterward, all 100,000 files were still sitting there inside one moved folder, taking up space. Emptying the bin is where the real deleting happens, and my 32.5 seconds doesn’t include that part.

These were single runs, so PowerShell and del could easily swap places on a repeat. Both still clearly beat every File Explorer option.

Now for the catch I mentioned. Both commands delete permanently. Nothing goes to the Recycle Bin, there’s no undo, and confirmation box asks if you’re sure. One mistake, and you’ve wiped the wrong folder. I copy the path from File Explorer’s address bar instead of typing it, wrap it in quotes, and run Get-ChildItem on it first to confirm it’s the folder I think it is. It’s one of the PowerShell commands I lean on to sort out messy folders, and it takes a second:

Remove-Item -Path "E:AppsNewfolder" -Recurse -Force

Robocopy’s reputation doesn’t hold up

Great at copying, slow at deleting

While Shift + Delete was the slowest method in this test, what’s interesting is how Robocopy performed. It’s often the first thing I see people recommend for handling large folders on Windows, and for good reason, since it’s a built-in copy tool that leaves File Explorer far behind.

The trick is to point Robocopy at an empty folder and tell it to mirror that folder onto the one you want gone. Since the source is empty, mirroring removes everything in the target, and you finish with an rmdir to remove the emptied folder:

robocopy "E:empty" "E:AppsNewfolder" /MIR

It works, but mirroring took 53 seconds on my test folder, which is almost as slow as Shift + Delete and twice as slow as a single PowerShell command. Adding multithreading with the /MT switch made it worse, taking up to 62 seconds across two runs. Robocopy is built to compare, copy, and sync files, and deleting is a side effect of mirroring rather than its main job.

So I wouldn’t use it to delete a large folder when Remove-Item and del + rmdir are faster. That said, Robocopy has one real advantage. It handles file paths longer than Windows’ traditional 260-character limit, which deeply nested folders like node_modules run into more often than you’d think. If rmdir or Remove-Item ever fails because a path is too long, the Robocopy mirror trick can still clear the folder.

Microsoft’s fix won’t help folders like this

Microsoft knows bulk deletion is slow. Earlier this year, it said it was testing changes to make bulk deletion more than 30% faster, and an Insider preview build released in July speeds up deleting large, fragmented files, but only in certain scenarios. That helps if you’re clearing a few huge video files or disk images off a nearly full drive. It does little for a folder like mine, where the time goes into handling 100,000 tiny files one at a time.

So for server logs or a bloated node_modules folder, Remove-Item is still the fastest way to clean up the junk. The Recycle Bin only moves the wait to later, and Shift + Delete makes you sit through all of it.