You check a file's properties and see two numbers that disagree. You copy a folder and the total changes. A backup tool reports something different again. None of these are errors — they are measuring genuinely different things. This page covers all six mechanisms, so you can tell which one you are looking at.
The main one
Size is how many bytes are in the file. Size on disk is how much storage was allocated, rounded up to a whole cluster — usually 4KB. A 1-byte file has a size of 1 byte and a size on disk of 4,096, because clusters cannot be shared between files.
Cluster allocation and slack
Filesystems do not track individual bytes. They allocate storage in fixed units called clusters (Windows) or blocks (Unix), most commonly 4KB. A file always occupies a whole number of them, and the unused remainder in the final cluster is slack space — allocated to that file and usable by nothing else.
For one file this is trivial. For a folder of many small files it dominates. The average waste is roughly half a cluster per file — about 2KB — so:
| Files | Average size | Total size | On disk | Overhead |
|---|---|---|---|---|
| 1,000 | 2 KB | 2 MB | 4 MB | 100% |
| 50,000 | 3 KB | 150 MB | 200 MB | 33% |
| 200,000 | 8 KB | 1.6 GB | 2.0 GB | 25% |
| 1,000 | 5 MB | 5 GB | 5.002 GB | 0.04% |
This is why a node_modules folder or a source repository can occupy twice its apparent size. It is also why cluster size is a real trade-off: larger clusters mean less fragmentation and faster sequential access, but more waste on small files.
💡 NTFS stores tiny files inside the file table
A file small enough to fit — under about 700 bytes — is stored inside its Master File Table record rather than being given a cluster. It is called a resident file, and its size on disk shows as 0, which looks like a bug and is actually an optimisation. It avoids both the wasted cluster and a second disk seek to read the contents.
Filesystem compression
When compression is enabled, size on disk can be smaller than size — the file is stored compressed and decompressed transparently on read.
Compression ratios follow the same rule as archives: it works once. Text, logs, CSV and source code compress by 60–90%. JPEG, MP4, PNG and ZIP files are already compressed and gain nothing — Windows detects this and stores them uncompressed rather than wasting CPU.
APFS on macOS and Btrfs and ZFS on Linux support transparent compression too, and all of them produce the same reporting result: a size on disk below the logical size.
Sparse files
A sparse file contains long runs of zeros that are not stored at all — the filesystem records "there are 10GB of zeros here" as a range, and materialises them only when read.
This is not a trick — it is how virtual machine disks, database files and disk images avoid consuming their full declared capacity before they hold anything. A "50GB" VM disk with 4GB of data genuinely occupies 4GB.
⚠️ Sparse files inflate when copied naively
A copy tool unaware of sparseness reads the zeros and writes them out as real data. A 10GB sparse file occupying 200MB becomes 10GB at the destination — and if the target disk has less than 10GB free, the copy fails for reasons that make no sense from the source folder's listing.
Use cp --sparse=always, rsync -S, or a backup tool that understands sparse files.
Hard links and deduplication
A hard link is a second name for the same data — not a copy and not a shortcut. Both names are equally real, the data exists once, and it is freed only when the last name is removed.
This makes folder sizes ambiguous in a way that is not resolvable in general. du counts each inode once, so a folder with a thousand hard links to one 1GB file reports 1GB. A tool that sums file sizes reports 1TB. Both are defensible answers to different questions.
It matters practically because several common systems use hard links heavily: Time Machine builds each backup from links to unchanged files, package managers such as pnpm link identical dependency files rather than copying, and incremental backup tools do the same. Copying such a folder without link awareness expands it enormously.
Modern filesystems add block-level deduplication, where identical blocks across different files are stored once. ZFS, Btrfs and Windows Server Data Deduplication all do this, and it makes reported free space genuinely unpredictable — writing a duplicate of an existing 10GB file may consume no additional space at all.
Alternate data streams and extended attributes
NTFS lets a file carry additional named streams beyond its main content. Most tools report only the main stream, so a file can occupy more disk than its stated size.
macOS has an equivalent in extended attributes, which is where Finder tags, quarantine flags and the remnants of resource forks live. Copy such a file to a filesystem that cannot store them — FAT32, exFAT, most network shares — and they are silently dropped, so the file gets smaller in transit.
Units — the simplest discrepancy
| Bytes | Windows | macOS | Linux ls -lh |
|---|---|---|---|
| 1,000,000 | 976 KB | 1 MB | 977K |
| 1,048,576 | 1.00 MB | 1.05 MB | 1.0M |
| 1,000,000,000 | 953 MB | 1 GB | 954M |
Windows divides by 1024 and labels the result MB. macOS divides by 1,000,000 and labels it MB. Linux tools divide by 1024 but usually label it with a bare M, or offer --si for decimal. Three conventions, one word, a 4.9% gap at megabyte scale.
Why folder totals never agree
Folder size is the least well-defined number in computing, because tools make different and equally reasonable choices about:
- Hidden files —
.gitcan be larger than the project it tracks. - System files —
.DS_Store,Thumbs.db,desktop.ini. - Symbolic links — count the link, or what it points to?
- Hard links — count once, or once per name?
- Slack space — logical size or allocated size?
- Directory entries — the folder structure itself occupies space.
- Permissions — files the tool cannot read are usually skipped silently.
✅ Which number to use
- Will it fit on this disk? → size on disk /
du - Will it fit in an email or upload? → logical size
- How long will the transfer take? → logical size, plus a large allowance for file count
- Am I within my cloud quota? → logical size, plus versions and trash
- Why is my disk full? → size on disk, always
Why transfers take longer than the size suggests
A related surprise: 1GB in one file copies far faster than 1GB in 100,000 files. Each file carries per-file overhead — creating a directory entry, allocating clusters, writing metadata, and on a network, a round trip or several.
| Content | Local SSD | Network share |
|---|---|---|
| 1 × 1 GB file | Seconds | Close to line speed |
| 1,000 × 1 MB files | Slightly slower | Noticeably slower |
| 100,000 × 10 KB files | Minutes | Hours |
The practical answer is to archive first. Zipping 100,000 small files into one archive and transferring that is frequently an order of magnitude faster than copying them individually, even accounting for the time to compress — because it converts hundreds of thousands of round trips into one sequential stream.
Checking a file arrived intact?
Generate a checksum before and after a transfer to confirm nothing changed — runs entirely in your browser.
Open the Hash Generator →Summary
- Size is content; size on disk is allocation rounded up to a cluster.
- Cluster slack averages 2KB per file — it dominates folders of small files.
- Compression and sparse files make size on disk smaller than size.
- Hard links are one file with two names, and tools disagree about counting them.
- Alternate data streams and extended attributes are invisible extra bytes.
- Windows uses 1024, macOS uses 1000, both call it MB.
- Use
dufor disk space, logical size for transfers. - Archive before moving many small files. File count matters more than total size.
Frequently Asked Questions
What is the difference between size and size on disk?
Size is how many bytes the file contains. Size on disk is how much storage the filesystem allocated to it, which is always rounded up to a whole number of clusters — typically 4KB. A 100-byte file has a size of 100 bytes and a size on disk of 4,096 bytes, because a cluster cannot be shared between files.
Why is size on disk smaller than size for some files?
Two possibilities. NTFS compression stores the data compressed, so the allocation is genuinely smaller than the logical content. Or the file is sparse — it contains large runs of zeros that are recorded as ranges rather than stored, which is common with virtual machine disks and database files.
Why does a folder show a different size on Windows and macOS?
Partly units and partly what is counted. macOS reports in decimal units where 1MB is 1,000,000 bytes, while Windows uses 1,048,576 — a 4.9% difference before anything else. macOS also creates hidden .DS_Store files, and the two systems count symbolic links and hard links differently.
Why does my cloud storage show a different size?
Cloud services generally report logical size and apply their own deduplication and compression behind the scenes, so what you are billed for may be less than what you uploaded. They also count file versions and trashed items against your quota, which never appear in a local folder listing.
Why does copying a folder produce a different total?
Almost always cluster slack. A folder of many small files occupies far more disk than the sum of its file sizes, and moving it to a filesystem with a different cluster size changes that overhead in either direction. Hard links are another cause — they count once at the source and become separate full copies at the destination.