A laptop shows PowerShell deleting a large project archive while File Explorer displays a 28% progress bar.
Deleting a big folder in File Explorer can feel like watching paint dry, and then watching the paint's own progress dialog calculate how long the paint will take. A new MakeUseOf test by Tashreef Shareef put numbers on it. On one Windows 11 25H2 laptop, the command line beat File Explorer at permanently removing a folder of 100,000 small files. The test also showed that the Recycle Bin's "fast" result is misleading, and that Robocopy, a popular workaround, is not the speed demon people assume.

Here is what the test found, why it happens, and how to do it safely.

A laptop shows PowerShell deleting a large project archive while File Explorer displays a 28% progress bar. Why File Explorer is slow at deleting large folders​

According to the report, File Explorer does a lot of bookkeeping around a delete.

  • It counts first. Before deleting anything, Explorer walks the whole folder tree to count files and total size. That feeds the progress dialog and its time estimate. On folders with hundreds of thousands of files, the scan alone can take minutes.
  • The Recycle Bin adds work. A normal delete moves items into the hidden $Recycle.Bin folder on each drive. Each item is renamed and paired with a small metadata record of when and where it was deleted. Windows also checks the total against the bin's size limit.
  • Permanent delete goes item by item. The report says Shift+Delete hands the job to the Windows shell. The shell removes files one at a time, keeps updating the progress dialog, and notifies other programs along the way.

These explanations are the author's account of Explorer's behavior. The benchmark measured total time. It did not measure how much each mechanism contributes.

The test setup​

The author built a folder that mimics a developer's node_modules directory.

  • 100,000 small .js files, about 50 MB in total
  • 5,500 folders: 500 top-level package folders, each with 10 lib subfolders holding 20 files
  • An HP Pavilion Gaming 15 with a Crucial MX500 SATA SSD
  • Windows 11 25H2 with Microsoft Defender switched on
  • A fresh copy of the folder for each method, timed with PowerShell's Measure-Command

The folder was kept small on purpose. That way the test measures the cost of handling each file, not the drive's raw write speed. The author ran the File Explorer methods through the same Windows shell function Explorer uses, so the timings are exact rather than stopwatch-based.

The results​

MethodTimeVersus fastest
PowerShell Remove-Item26.2 s1.0x
del + rmdir28.4 s1.1x
File Explorer, Recycle Bin32.5 s1.2x
Robocopy /MIR53.2 s2.0x
File Explorer, Shift+Delete57.1 s2.2x

Treat these as illustrative, not as a general benchmark.

  • These were single runs. The author concedes that PowerShell and del could swap places on a repeat.
  • They come from one machine. Your disk, folder layout, antivirus and Windows build will change the numbers.
  • The ordering still matters. Both command-line methods clearly beat every File Explorer option in this test.

The Recycle Bin number is not a real deletion​

The Recycle Bin's 32.5 seconds looks respectable, but the author checked $Recycle.Bin afterward. All 100,000 files were still there inside one moved folder, still taking up space. The reported figure doesn't include emptying the bin, which is where the real deleting happens. The Recycle Bin defers the wait. It doesn't remove it.

So the like-for-like comparison for permanent removal is PowerShell at 26.2 seconds, del + rmdir at 28.4 seconds, and Shift+Delete at 57.1 seconds. In this test, Shift+Delete took more than twice as long as PowerShell.

How to delete a large folder from the command line​

PowerShell​

Remove-Item -Path "E:\Apps\Newfolder" -Recurse -Force

Microsoft Learn describes the pieces this way.

  • -Recurse is not what the Learn page says here, so rely on the Learn documentation itself: -Recurse deletes the items in the specified location and all of their child items.
  • -Force removes items that can't otherwise be changed, such as hidden or read-only files. Even with -Force, the cmdlet can't override security restrictions.
  • -WhatIf shows what would happen without running the command. It's a handy dry run, but you still have to check the path yourself.

Command Prompt​

The test used two commands in sequence:

Code:
del /f /s /q "E:\Apps\Newfolder\*"
rmdir /s /q "E:\Apps\Newfolder"

The exact del target pattern is my illustration. The report only names the switches del /f /s /q followed by rmdir /s /q. Microsoft documents rmdir (same as rd) like this.

  • /s deletes the directory tree, including all subdirectories and files.
  • /q is quiet mode and skips the confirmation prompt. Microsoft's own caution says the whole tree is deleted without confirmation.
  • You can't remove the current directory. If you get that error, change to a different directory that is not a subfolder of the target and try again.
  • A "directory is not empty" message can mean hidden or system files remain. Microsoft suggests dir /a to list them and attrib to clear the attributes.

What success looks like​

The folder is gone from File Explorer, and Get-ChildItem on its former path reports that it can't be found. Free space on the drive rises accordingly. A Recycle Bin delete won't show that last change until you empty the bin.

Safety: there is no undo​

Both command-line methods delete permanently. Nothing goes to the Recycle Bin and there is no undo. Remove-Item with -Recurse doesn't ask first. The author's routine is sensible:

  1. Copy the path from File Explorer's address bar instead of typing it.
  2. Wrap it in quotes.
  3. Run Get-ChildItem on that path first and confirm the contents are what you expect.
  4. Only then run the delete.

For extra caution, add -WhatIf to the Remove-Item command first. -Force doesn't make a delete safer or recoverable. It only makes more items eligible for removal.

Robocopy: the workaround that isn't faster​

The common trick is to mirror an empty folder onto the one you want gone. The author's example:

robocopy "E:\empty" "E:\Apps\Newfolder" /MIR

You then finish with rmdir to remove the emptied folder. It works, but it took 53.2 seconds, nearly as slow as Shift+Delete. Adding /MT made it worse, up to 62 seconds across two runs. The author's view is that Robocopy is built to compare, copy and sync, and deleting is a side effect of mirroring.

Microsoft's reference matches the mechanism. /MIR is equivalent to /E plus /PURGE. /PURGE deletes destination files and directories that no longer exist in the source. The reference also notes that /MIR with /E can overwrite the destination directory's security settings. Microsoft documents /MT as a multithreaded copy option, and that documentation doesn't say it speeds up deletion.

Mixing up source and destination here is a data-loss recipe. Double-check the order before you press Enter.

The one reason to still use it​

The author says Robocopy handles paths longer than the traditional 260-character limit. Deeply nested node_modules trees hit that limit often. If rmdir or Remove-Item fails because a path is too long, the mirror trick may still clear the folder. That is the author's practical observation, not a guarantee for every system. Microsoft's reference only says that /256 turns off support for paths longer than 256 characters.

What about Microsoft's own fixes?​

Microsoft has been working on this for a while.

  • 2023: A Windows Developer Blog post on performance said Microsoft improved bulk file delete operations by over 40%. It added that deleting many files at once is rare for most users, but the work shows the breadth of the effort.
  • June 2026: Windows Latest reported that Microsoft said bulk delete would be more than 30% faster. The plans came out at a Windows Insider meetup in the United States, according to Windows Report. TechRepublic described the claim as reported testing, not a shipped feature.
  • July 2026: Windows Latest reported that Windows 11 Insider Experimental Preview Build 26300.8935, released July 20, deletes large, fragmented files faster. Microsoft's note says the speedup applies "in certain scenarios", namely large, fragmented files.
  • Broader File Explorer work: In a July 31, 2026 update, Windows chief Pavan Davuluri said File Explorer improvements would reach Windows 11 PCs more broadly starting this fall. That post speaks of File Explorer responsiveness and reliability in general. It doesn't confirm the specific delete-speed figures.

The MakeUseOf author argues the July change won't help a folder of 100,000 tiny files. His reasoning is that the time goes into per-file handling, not into big fragmented files. That is a reasonable reading of the "certain scenarios" wording. It is the author's judgment, not something Microsoft has said, and nobody has yet published a test of the preview build on this kind of workload.

Practical takeaways​

  • Large folder, permanent removal, and you're sure of the path: PowerShell Remove-Item -Recurse -Force or del + rmdir was fastest in this test.
  • Want a safety net: use the Recycle Bin, but remember that emptying it is where the real deletion happens.
  • Shift+Delete in Explorer: it was the slowest option here, so avoid it for huge trees if time matters.
  • Path-length errors: the Robocopy mirror is a fallback, used carefully.
  • Expect variation: Defender scans, spinning disks and different folder shapes can all shift the numbers. If you do this regularly, time it on your own setup.

For developers and admins who clear node_modules or log folders regularly, the lesson is simple. File Explorer does the polite thing, and the polite thing takes longer. The shell trades the progress bar for speed, and it also drops the safety net.

 

References

  1. Windows File Explorer makes deleting large folders painfully slow, but there's a faster way MakeUseOf 2026-11-06T17:00:18+00:00
  2. Remove-Item (Microsoft.PowerShell.Management) - PowerShell | Microsoft Learn learn.microsoft.com
  3. Delivering Delightful Performance for More Than One Billion Users Worldwide - Windows Developer Blog blogs.windows.com