Same 1 GB, Yet a Photo Folder Copies Slower Than a Single Video — Why?

A 1 GB video copied in no time, yet a photo folder that totals 1 GB seems to take forever. You moved to a new SSD, but the transfer speed drops sharply as soon as you move lots of small files.

If the size is the same, the time ought to be the same too — but what decides copy time is not only “how many bytes to move” but also “how many files to handle.”

This article is an introduction for everyday users who copy photos and documents to external drives or a NAS on Windows 11. It explains the mechanism, then shows a procedure for comparing data of the same total size yourself. It is based on official documentation checked on September 5, 2026, and is not the result of measuring the speed of any particular PC or NAS.

1. “Moving 1 GB” and “Processing 10,000 Items” Are Different Jobs

Think of a house move: even when the total weight is the same, one large box and 10,000 small parcels whose address labels each have to be checked are not the same amount of work. Files, too, involve work before and after the contents are moved.

flowchart TB
    accTitle: The same size, a different number of files
    accDescr: Even with 1 GB of data in total, one file and many files require a different number of management operations.
    A["1 GB of data in total"] --> B["One large file"]
    A --> C["10,000 small files"]
    B --> D["Few per-file operations"]
    C --> E["Per-file operations repeated"]

Figure 1: The same number of bytes does not mean the same number of files.

Microsoft, too, explains that when many small files are copied one after another across a network, work other than data transfer takes over and the line speed cannot be fully used.¹

Of course, this is not a rule by format along the lines of “photos are slow, videos are fast.” A handful of large photos and tens of thousands of tiny images are different situations. Start by opening the folder’s Properties and looking at both the total size and the file count. For the comparison, match the total number of bytes of file contents, not “Size on disk.”

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (11 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. A Copy Handles More Than the Contents

When a file is copied, the source is opened, the destination file is created, the contents are read and written, the required information is set, and the file is closed. Opening a file on Windows also involves conditions such as access rights and whether other operations may open the file at the same time.²

The information used to manage a file, such as its name, size, and timestamps, is called metadata. The NTFS file system, for example, records per-file management information in structures such as the MFT (Master File Table). It is not a mechanism where writing the photo’s pixel data is all there is to it.³

flowchart TB
    accTitle: The work involved in copying one file
    accDescr: Besides reading the source, creating the destination, managing its information, and closing it are required for each file.
    A["Open the source"] --> B["Create the destination"]
    B --> C["Read and write the contents"]
    C --> D["Set the information and close"]
    D -.-> E["Repeat for the next file"]

Figure 2: A conceptual flow. The actual order of operations and any parallel execution depend on the copy method and the file system.

An SSD does not make this management work disappear. The large transfer-rate figure on a product’s spec sheet alone cannot tell you how long 10,000 files will take to copy. It is also too crude to simply call copying small files “all random I/O.” Beyond where the reads and writes land, the file-handling work itself has to be considered separately.

3. On a NAS, “Waiting for the Other Side to Reply” Is Added

A NAS is a storage device used over the network. With SMB (Server Message Block), the protocol behind Windows shared folders, file operations are requested from the other side, and there are points where the PC waits for that side to process the request and respond.

flowchart TB
    accTitle: File operations across a network
    accDescr: An operation request from the PC travels across the network, becomes a file operation on the other side, and the response returns to the PC.
    A["PC requests a file operation"] --> B["Travels across the network"]
    B --> C["Other side processes the file"]
    C --> D["Response returns to the PC"]

Figure 3: Being able to move a lot at once and getting a quick reply to a single operation are two different things.

Bandwidth corresponds to the number of lanes on a road; latency corresponds to the time until a reply comes back. When the wait per small file grows, the amount transferred does not increase even with bandwidth to spare. Antivirus scanning can also affect the processing time per file.¹

This does not mean, however, that every file always requires a fixed number of round trips. SMB has a mechanism for bundling requests, and caching and concurrency conditions also change how the waiting plays out.⁴⁵ Results also differ between a home LAN and a shared folder at a remote site.

A Simplified Example for Thinking in Numbers

Assuming everything is processed in sequence with no overlap, the reasoning goes like this.

Copy time ≈ total bytes ÷ data transfer rate
          + number of files × extra time per file

This is neither a measured value nor Windows’ exact formula. For illustration, assume the data portion runs at 100 MB/s and the extra time is 2 milliseconds per file. Here 1 GB = 1,000 MB.

The 1 GB data portion takes 10 seconds. With one file the extra time is 0.002 seconds, but with 10,000 files it is 20 seconds, for a total of about 30 seconds. The model leaves out parallelism, caching, and CPU and storage limits, but it does explain why “the same size takes a different amount of time.”

flowchart TB
    accTitle: Splitting copy time into two parts
    accDescr: Distinguishes the transfer time determined by total size from the extra time that accumulates with the number of files.
    A["Time proportional to total size"] --> C["Total copy time"]
    B["Extra time proportional to file count"] --> C

Figure 4: As the file count grows, time that was invisible from the data volume alone starts to matter.

4. ZIP Does Not Just “Shrink” — It Also “Bundles Into One”

ZIP has two roles: compressing data and bundling multiple files into a single container. JPEG is already a compressed format, so putting it in a ZIP may not reduce the size much.⁶

Even so, there is a separate effect: the number of files handled during transfer drops from 10,000 to one. Looking only at the compression ratio and concluding “the ZIP was pointless” is premature.

flowchart TB
    accTitle: The two roles of ZIP
    accDescr: The change in file count from bundling into a ZIP and the change in size from compression are separate effects.
    A["Bundle the photos into a ZIP"] --> B["One file to transfer"]
    A --> C["Size change depends on the contents"]

Figure 5: Even when almost nothing compresses, the number of files to transfer goes down.

Neither bundling nor extracting is free, though. If you want to use the photos as an ordinary folder, compare the following total.

Time via ZIP = ZIP creation + ZIP transfer + extraction

Creating the ZIP reads the small files, and extraction creates them again at the destination. The point is not to eliminate the per-file work but to change where that work happens and the form of the transfer. If the processing before and after the transfer is heavy, not bundling can be faster.¹

5. “Where You Extract” Changes What ZIP Buys You

If you send the ZIP to the receiving PC and extract it on that PC’s local drive, the small files do not have to be streamed across the network one at a time. Microsoft’s guidance also lists extracting the archive on the destination system as a method.¹

flowchart TB
    accTitle: Extracting on the destination versus extracting from the PC to the share
    accDescr: Distinguishes the path where the destination extracts internally from the path where the PC writes the extracted files to the share.
    A["Send the ZIP to the destination"] --> B["Destination extracts internally"]
    C["PC app extracts"] --> D["Small files sent to the share"]

Figure 6: “The ZIP is on the NAS” does not by itself mean the extraction is performed inside the NAS.

This is an easy place to get wrong. If you open a ZIP on the NAS in File Explorer on the PC and choose the same shared folder as the extraction target, the PC writes the extracted small files to the NAS, so the fine-grained network operations happen all over again.

Distinguish this from the case where the NAS itself has a supported extraction feature that can run inside the NAS, from its management console or the like. If no such feature exists, do not settle for “sending a ZIP solves it”; measure the whole path you will actually use. When comparing extraction inside the NAS with extraction to the PC’s local drive, also keep in mind that the final location of the files is different.

6. Comparing Large, Small, and ZIP at the Same 1 GB

You can start by trying it with a video and photos you already have. But since the contents, file count, and compressibility all differ, use test data when you want to isolate the cause. What follows is not a set of measured speeds but a comparison procedure to run in your own environment.

Prepare three things: one large file, 10,000 small files, and an uncompressed ZIP that bundles those 10,000 files. The contents of A and B both total exactly 1,000,000,000 bytes. C carries ZIP’s management information on top, so its file size will not match A and B exactly.

flowchart TB
    accTitle: Three kinds of comparison data
    accDescr: Create one large file and a set of small files with the same total size, then create an uncompressed ZIP from the latter.
    A["Prepare the same 1 GB total"] --> B["One 1 GB file"]
    A --> C["10,000 files of 100 KB"]
    C --> D["Same contents into an uncompressed ZIP"]

Figure 7: With an uncompressed ZIP, it is easier to observe the effect of bundling the files separately from any difference in compression ratio.

Creating the Test Files (Optional)

This is for readers who can use the command line. In Windows PowerShell 5.1 or later, create a new test folder in the local temporary folder. The large file and the small files alone take about 2 GB, about 3 GB including the ZIP, and the destination needs its own free space as well. To avoid filling the disk, make sure the source has at least about 5 GB free.

No existing photos or documents are used. The data is generated from pseudo-random numbers, so the files cannot be opened as videos or photos. This avoids the extreme compression you would get with zero-filled data alone, but it does not reproduce scanning or application behavior for real photos.

$ErrorActionPreference = 'Stop'
$lab = Join-Path ([System.IO.Path]::GetTempPath()) ('copylab-' + [guid]::NewGuid().ToString('N'))
$drive = New-Object System.IO.DriveInfo ([System.IO.Path]::GetPathRoot($lab))
if ($drive.AvailableFreeSpace -lt 5GB) {
    throw 'Make sure the test drive has at least 5 GB of free space.'
}
$largeDir = Join-Path $lab 'large'
$smallDir = Join-Path $lab 'small'
[System.IO.Directory]::CreateDirectory($largeDir) | Out-Null
[System.IO.Directory]::CreateDirectory($smallDir) | Out-Null
Write-Host "Created at: $lab"

$fileCount = 10000
$buffer = New-Object byte[] 100000
$random = New-Object System.Random 20260905
$large = [System.IO.File]::Open(
    (Join-Path $largeDir 'one.bin'),
    [System.IO.FileMode]::CreateNew,
    [System.IO.FileAccess]::Write,
    [System.IO.FileShare]::None
)
try {
    for ($i = 0; $i -lt $fileCount; $i++) {
        $random.NextBytes($buffer)
        $name = 'part-{0:D5}.bin' -f $i
        [System.IO.File]::WriteAllBytes((Join-Path $smallDir $name), $buffer)
        $large.Write($buffer, 0, $buffer.Length)
    }
}
finally {
    $large.Dispose()
}
Write-Host "Preparation complete. The contents of each data set are $([long]$fileCount * $buffer.Length) bytes."

The same byte sequence is written both to the small pieces and to the single file. Next, in the same PowerShell window, create the uncompressed ZIP. Record the creation time here. NoCompression stores the files in the ZIP without compressing them.⁷

$zip = Join-Path $lab 'small.zip'
$watch = [System.Diagnostics.Stopwatch]::StartNew()
Compress-Archive -LiteralPath $smallDir -DestinationPath $zip -CompressionLevel NoCompression
$watch.Stop()
Write-Host "ZIP creation: $($watch.Elapsed.TotalSeconds) seconds"
Write-Host "ZIP size: $((Get-Item -LiteralPath $zip).Length) bytes"

This procedure is only for the generated ordinary files. Compress-Archive has limitations such as ignoring hidden files, so do not reuse it as is for a complete backup of an important folder.⁷ If it stops with an error, do not use that run for measurement; check the test folder whose path was displayed. Clean up only after confirming that the folder is the one you created yourself.

Keeping the Measurement Conditions the Same

Use the same source and destination devices, the same network, and the same copy method. To begin with, copy all three in File Explorer; do not use move. Make the destination a new, empty folder every time so that skipping of existing files or overwrite prompts do not get mixed in.

flowchart TB
    accTitle: Procedure for keeping comparison conditions the same
    accDescr: Fix the copy path and method, copy to an empty destination several times in varying order, and check the contents after completion.
    A["Same devices, path, and method"] --> B["Empty destination every time"]
    B --> C["Measure several times in varying order"]
    C --> D["Check count and contents too"]

Figure 8: Do not treat time saved by skipping files that were already copied as a faster transfer.

Measure each case, say, three times, varying the order, and record the median and the spread. Windows caches files in memory, so only the second run may come out faster. A new destination does not clear the cache on the reading side. What this procedure reveals is a tendency close to everyday copying, not strict cache-free media performance.⁵

Copies within the same physical drive have reads and writes competing with each other, so do not mix them with copies to a separate device. Do not use online-only cloud files, because the time to fetch them would be included, and do not change conditions such as antivirus or sync partway through.

This is a table for recording; no result figures are filled in. A is a control for observing the characteristics of the transfer; because its file structure is different, it is not a substitute for B. For the practical comparison between B and C, the goal is to place the same set of files in the same final location. Always record where the extraction was done as well.

After copying or extracting, cross-check the file count and total bytes, and verify the contents with hashes if necessary. Do the verification reads outside the measurement, and note that they also affect the cache for the next trial. The time until the copy dialog closes does not measure the time until the data can survive a power loss, so do not experiment with unplugging an external device right afterward either.⁵

7. When You Cannot Use a ZIP, Copy in Parallel a Little at a Time

For uses where individual files must be usable at the destination right away, or where only the files that changed are sent each time, bundling into a ZIP may not be a good fit. Windows’ built-in robocopy has /MT, which handles multiple files in parallel.⁸⁹

flowchart TB
    accTitle: Overlapping the per-file wait in parallel
    accDescr: By working on several files at once, another transfer can proceed while one file is waiting.
    A["Handle several files at once"] --> B["File A waits for a response"]
    A --> C["File B is transferring"]
    B --> D["Waits overlap"]
    C --> D

Figure 9: Parallelism is a way to overlap waits; it does not make the line or the disk itself faster.

The following example copies from the $smallDir created earlier. Change only $targetRoot to a destination you can write to. Create a separate destination folder for each run, and do not use options that delete the source data or the destination.

$targetRoot = '\\NAS\share\CopyLab' # change to your own destination
$runId = [guid]::NewGuid().ToString('N')
$target = Join-Path $targetRoot ('small-mt8-' + $runId)
$log = Join-Path $lab ('robocopy-' + $runId + '.log')
robocopy $smallDir $target /E /MT:8 /R:1 /W:1 /XJ "/LOG:$log"
$code = $LASTEXITCODE
if ($code -ge 8) {
    throw "The copy had failures. Exit code=$code, log=$log"
}
Write-Host "Exit code=$code. Check the copied and failed counts in the log and the contents of the destination: $log"

/MT:8 means 8 threads, /R:1 /W:1 are the retry count and the wait in seconds on failure, and /LOG saves the log. robocopy reports a successful copy even with exit code 1, and 8 or higher includes failures. That does not mean 0 to 7 excuses you from checking the contents.⁸

/MT:8 is an example starting point for the comparison, not an optimal value. Too much parallelism increases the load on the other side and can actually make things slower.¹ Limit what you change at a time, for instance by comparing /MT:1 and /MT:8 with the same method. Do not judge the effect of either from a result where the ZIP and the parallelism were changed at the same time.

8. Before Concluding “It Is Slow, So It Must Be Broken”

Is it only the many small files that are slow, or are large files slow too? What happens when the same files are copied locally? Separating these narrows down where to look. When the speed drops partway through, the cache may be involved, and the displayed speed alone cannot pinpoint the cause.⁵

flowchart TB
    accTitle: Isolating slow copies
    accDescr: Investigates slowness limited to small files separately from slowness regardless of the type of data.
    A{"Only small files slow?"} -->|Yes| B["Look at file count and wait time"]
    A -->|No| C["Also check device, connection, and load"]
    B --> D["Also check for failures or disconnects"]
    C --> D

Figure 10: Speed that does not scale with small files and copy failures or device faults are not the same story.

When copy failures or disconnections occur, or things suddenly got much worse than before, do not stop at explaining it by file count alone. Put preserving important data first, and check the logs and the state of the devices.

Also, stopping antivirus or disabling SMB signing to gain speed is not recommended. SMB signing serves to prevent tampering with the communication, among other things.¹⁰ On a managed PC, do not work around the settings; consult the person in charge.

Summary

Copy time consists of both time proportional to the amount of data and work proportional to the number of files. That is why “it is 1 GB, so it takes the same time” does not necessarily hold.

If you try a ZIP, look beyond the compression ratio to creation, transfer, and extraction. If you try parallel copying, change only the number of threads at a time. Before buying faster hardware, looking at the total size and the file count together makes it easier to reason about what is happening on your Windows right now.

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Why does a photo folder copy slower even though the size is the same?

A copy is not just a transfer of contents. For every file, the destination file is created, its information is managed, it is closed, and so on. When there are many small files, the share of this processing and waiting grows. What matters is not the photo format itself but the number of files and the size of each one.

Do small files still copy slowly on an SSD or a fast LAN?

Yes. Even on an SSD the file management work remains, and when copying to a NAS or similar, the time spent waiting for the network and for the other side's processing is added. The speed of a continuous transfer of large files and the speed of handling many small files are two different things.

If JPEGs do not get smaller in a ZIP, is there any point in bundling them?

Even when the size barely shrinks, bundling the files to be transferred into one still has an effect. Creating and extracting the ZIP take time as well, though. For uses that require extraction, compare the total time of creation, transfer, and extraction.

Is it faster to send a ZIP to the NAS and then extract it into the shared folder from the PC?

With that method the PC writes the extracted small files to the NAS, so file creation across the network happens all over again. Distinguish this from extracting inside the NAS with a feature the NAS itself supports, and measure with the extraction included.

Does robocopy's parallel copy get faster the more threads you add?

No. Parallelism lets the per-file waits overlap, but it also increases the load on the storage or the NAS. Compare under the same conditions starting from a small number of threads, and check the log for copy failures and missed files as well.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.