Robocopy vs File Explorer: Speed Up Small File Copies on Windows 11 Safely

Why 300MB can take longer than 5GB​

Onyimadu's test on Windows 11 25H2 (build 26200.9457) used a WD SN530 NVMe SSD. Explorer needed about 30 seconds to copy roughly 5,000 generated text files totaling around 300MB. That works out to about 10MB/s. A single 5GB file on the same drive copied at around 260MB/s.

The explanation is per-file overhead. Every file needs its own open, write, close and bookkeeping steps. With tiny files, that overhead can outweigh the data movement. Explorer also spent about three seconds "calculating" before it began copying.

This matches Microsoft's own guidance for Azure Files migrations. For large namespaces with many small files, namespace enumeration speed can matter more than throughput, and 1 TiB of small files takes considerably longer than 1 TiB of larger files.

That also explains the progress bar that races to about 90% and then crawls. The author noticed this while copying project folders. That is an anecdote, and the article doesn't prove why the bar behaves that way.

What the Robocopy tests showed​

Robocopy is a built-in command-line tool, so there's nothing to install. The command used was:

robocopy "C:\Source" "D:\Destination" /E /MT:16 /NFL /NDL /NP /LOG:C:\copy.log

Replace the paths with your own. The switches do the following:

• /E copies subfolders, including empty ones.
• /MT:16 copies 16 files at once.
• /NFL, /NDL and /NP suppress file names, directory names and progress output.
• /LOG: writes the results to a file, so you have to open the log to see what happened.

The author's results, as the median of three runs with the destination cleared each time:

Single-threaded Robocopy was essentially tied with Explorer. The gain came from running files in parallel, not from Robocopy being inherently quicker. Gains flattened after about 16 threads. One-second gaps fall within the author's run-to-run noise, so 16, 32 and 64 shouldn't be ranked against each other. A rerun of Explorer and /MT:1 gave the same 30 and 29 seconds, which argues against a warm file cache skewing the numbers.

The author doesn't know why the curve flattens. The guesses are the drive, antivirus scanning or another per-file bottleneck. Treat those as hypotheses.

The single big file​

For one 5GB file, Explorer took about 19 seconds. Robocopy with /MT:1, /MT:16 and /J took the same time. That fits the mechanism, because /MT parallelizes across files and one file gives it nothing to split. It's one test on one drive, though. An older blog benchmark by Andy's Tech Blog reported a large single file copying nearly twice as fast with multithreading, so don't treat "no benefit for big files" as a rule.

What Microsoft's documentation says​

Microsoft's Robocopy reference confirms the basics:

• /MT:n creates multithreaded copies, n must be between 1 and 128, and the default is 8.
• For better performance, Microsoft advises redirecting output with /LOG. That supports the logging part of the author's command.
• The reference page's syntax is robocopy <source> <destination> [<file>[ ...]] [<options>]. Source comes first.

One wrinkle is that plain /MT with no number means 8 threads, but omitting /MT entirely means no multithreading. A commenter on Andy's Tech Blog made this point. Microsoft's reference itself documents /MT as "creates multi-threaded copies" with a default n of 8.

Don't copy the benchmark blindly​

Microsoft's own Q&A guidance suggests the best thread count depends on the machine. One answer says to experiment with different values and watch performance, and notes that too many threads can cause excessive disk I/O. That is a community answer, not official documentation, but it matches what the 128-thread result showed.

The author also limits the scope. The test used a single NVMe drive and generated text files. He wouldn't use it to predict how photos, hard drives, USB sticks or network shares behave. Real source code or Office documents, with antivirus scanning and different file sizes, may give different numbers.

Gotchas that can bite you​

Swapped paths. The author deliberately reversed source and destination, and Robocopy copied in the opposite direction without asking. Check both paths before you press Enter.

Contents, not the folder. Robocopy copies the contents of the source folder into the destination. It doesn't create a "Source" folder inside it.

/MIR can delete files. Microsoft defines /MIR as equivalent to /E plus /PURGE. /PURGE removes destination files that no longer exist in the source. If you swap paths with /MIR, you can wipe the wrong folder. Microsoft defines /L as listing files without copying, deleting or timestamping them. The author recommends running /L first. Reserve /MIR for cases where you truly want a mirror.

The retry defaults are huge. Microsoft documents the defaults as 1,000,000 retries and a 30-second wait. A copy that hits a locked file can look hung for a very long time. Setting /R:1 /W:1 avoided stalls in the author's test, which had no locked files. A real workload may need different values.

Restartable mode costs speed. /Z took about 25 seconds against about 22 in the author's test, roughly 14% slower. Microsoft describes it as letting an interrupted copy resume. It may be worth the cost on flaky links.

A sensible way to try it​

1. Open a Command Prompt or terminal window.
2. Write the source and destination paths out and confirm their order.
3. Run a command like the one above, starting with /MT:8 or /MT:16.
4. Open the log file and check for failures. Microsoft says any exit code of 8 or higher means at least one failure.
5. Time a couple of thread counts on your own data, and stop raising the count once it stops helping.

Bottom line​

For large batches of small files, Robocopy with /MT is a worthwhile experiment. In this test it saved about a quarter of the time, and single-threaded Robocopy gained almost nothing. It is a command-line tool with sharp edges, and the numbers come from one machine. The safest advice is to test on your own drives and keep /MIR away from anything you can't afford to lose.