Looking at the properties for a Windows file I get two attributes, “Size” and “Size on disk,” and "Size on disk" is always larger.

What do these two metrics mean?


6 Answers 6


Size is the actual size of the file in bytes.

Size on disk is the actual amount of space being taken up on the disk. They differ because the disk is divided into tracks and sectors, and can allocate blocks of discrete size.

For a more detailed explanation, see this text which I copied from another site:

We know that a disk is made up of Tracks and Sectors. In Windows that means the OS allocates space for files in "clusters" or "allocation units".

The size of a cluster can vary, but typical ranges are from 512 bytes to 32K or more. For example, on my C:\ drive, the allocation unit is 4096 bytes. This means that Windows will allocate 4096 bytes for any file or portion of a file that is from 1 to 4096 bytes in length.

If I have a file that is 17KB (kilo bytes), then the Size on disk would be 20.48 KB (or 20480 bytes). The calculation would be 4096 (1 allocation unit) x 5 = 20480 bytes. It takes 5 allocation units to hold a 17KB file.

Another example would be if I have a file that is 2000 bytes in size. The file size on disk would be 4096 bytes. The reason is, because even though the entire file can fit inside one allocation unit, it still takes up 4096 of space (one allocation unit) on disk (only one file can use an allocation unit and cannot be shared with other files).

So the size on disk is the space of all those sectors in which the file is saved. That means,usually, the size on disk is always greater than the actual size.

So the actual size of a file(s) or folder(s) should always be taken from the Size value when viewing the properties window.

Source: What's The Difference Between Size And Size On Disk In Windows Folder Properties.

  • 1
    So should I look at "size" or "size on disk" when I wish to compare the percentage of how much a folder takes compared to the total that the current partition has? Commented Oct 24, 2014 at 23:17
  • 1
    @androiddeveloper size on disk it is
    – Am1rr3zA
    Commented Oct 24, 2014 at 23:36
  • 8
    The answer by Synetech below adds important (and potentially confusing) points about Compression and Hard links, both of which can lead to a Size on Disk that is smaller than the Size. Commented Nov 21, 2014 at 18:04
  • 1
    @baroquedub You can have massive difference between the two (like the x1000 factor in your example). This difference can happen especially if there are lots of small files (basically because files are written as "blocks" on the disk, so at least the whole size of one block will be taken. The actual size of the block depends on the file-system, so the size on disk taken may be different on different disks.
    – Pacopaco
    Commented Jan 16, 2019 at 15:03
  • Note that if you have Nextcloud and use the Virtual Files feature, size will show the actual file size on the cloud, and size on disk will show the size of files you selected to be available locally.
    – Alex
    Commented Feb 8 at 16:07

It has to do with the allocation unit sizes used on your disk when it was first formatted.

Imagine you have two 2 x 10 gallon gas cans in your car. Each gas can is an allocation unit. You need to get 12 Gallons of gas, so you need to use both cans. Basically using 20 Gallons of allocated space - but only filling 12 gallons.

Here is the default size for Windows XP

 Drive size   
 (logical volume)             Cluster size          Sectors   
 512 MB or less               512 bytes             1
 513 MB - 1,024 MB (1 GB)     1,024 bytes (1 KB)    2 
 1,025 MB - 2,048 MB (2 GB)   2,048 bytes (2 KB)    4
 2,049 MB and larger          4,096 bytes (4 KB)    8

If you think of the Cluster size as each of your gas cans: Holding 4KB of "gas" each. But your file is 2KB then the fills size is 2K, but size on disk is 4KB

  • 9
    Allow me to add to your answer. The allocation unit (bucket) size is chosen based on the size of the disk. If you're using a bucket to empty a bathtub, you would choose a smallish bucket. If you're emptying a swimming pool, you'll use a bigger bucket.
    – Les
    Commented Nov 6, 2009 at 20:47

Cluster Slack Space

You cannot access each individual byte on a storage medium separately. To do so would be terribly inefficient because the system needs some way of keeping track of which ones are used and which are free (i.e., a list), so doing so for each byte separately would create too much overheard (for each individual byte, i.e. 1-to-1, the list would be as big as the medium itself!)

Instead, the medium is broken up into chunks, blocks, units, groups, whatever you want to call them (the technical term is clusters), each of which contains a—consistent—number of bytes (you can usually specify the size of the clusters since different uses call for different sizes to reduce waste).

When a file is saved to disk, the size of the file is divided by the cluster size and rounded up if needed. This means that unless the filesize is exactly divisible by the cluster size, some of the cluster ends up being unused and thus wasted.

When you view the properties for a file, you see the true size of the file as well as the size it takes up on disk which includes any “slack”, that is, the “cluster tips” that are unused. This is usually not much per-file and the size on disk will usually be almost equal to the actual size, but when you add up the wasted space from all the thousands of files on a drive, they can add up. Therefore, when you view the size of a large folder, especially one with many tiny files that are smaller than a cluster, the size on disk (i.e., the amount of disk space marked as used) can end up being significantly larger than the actual size (i.e., the amount space the files actual require).

In a case like above, what you can try is to reduce the cluster size so that each file wastes less space. Generally, a drive with mostly lost of little files should use the smallest cluster size possible (to reduce waste) and a drive with mostly large files should use the largest cluster size possible (this way the bookkeeping structures end up being smaller).

Even at a lower level, if each cluster is only a single sector, unless a file is an exact multiple of the size of the sectors on the drive (usually 512 bytes traditionally, now often 4,096 with Advanced Format disks), then there will still be unused space between the end of the file and the end of the sector.


Another scenario where you might see a difference between the actual file size and size on disk is with compression. When a drive is compressed (e.g., using DriveSpace, NTFS compression, etc.) then there will be a difference between the size of the actual file (which needs to be know), and the actual size that the file occupies (i.e., uses or “takes up”) on the disk.

Shortcuts and Hardlinks

Yet another scenario that could result in a difference is with hardlinks. With file-systems that support hardlinks, when a duplicate file is created, instead of making a whole new file that takes up space for itself, the file-system creates a shortcut to the file so that both (or all three, etc.) copies point to the same physical file on disk. Therefore, when there are two files pointing to the same data, they each have the same size, but take up only slightly more than the space to store a single copy.

  • 1
    Actually with 1B allocation units, the list wouldn't necessarily take up the entire medium. Just an eighth of the size. This is because you only need a single bit to say whether a block is used or free.
    – Sparkette
    Commented Dec 28, 2016 at 7:06
  • Overhead also includes data that indicates several allocation units belong to the same file. If you say each byte has another bit indicating if the data overflows into the next byte, that solves that but is too naive for modern disk size/performance because if the next byte isn't free EVERY byte of the hard drive may need to be moved. Realistically, you'd need more overhead in order to specify offset of next allocation unit or assign a file id of sorts to each allocation unit. Commented Feb 6, 2017 at 19:58
  • @flarn2006, theoretically maybe, but there's no such thing as 1-byte allocation units; the minimum is a single sector which is 512 (or 4,096 with Advanced Format disks).
    – Synetech
    Commented Nov 1, 2019 at 21:04
  • @RetiredAssistant, the overhead of the MFT/FAT is not indicated in the size/on-disk field by Windows.
    – Synetech
    Commented Nov 1, 2019 at 21:05

Another thing that may significantly reduce the Size on Disk value are situations where a file is not actually stored on disk but is still accessible through various means.

For example, the Offline Files feature of OneDrive enables a user to store a file in such a way that it is accessible via an internet connection. The file still exists on disk and has a certain size, but because it is not on disk until it is downloaded, it takes up no space.

Properties window of the OneDrive folder. The size of the folder is 171 GB, but the size on disk is 31.7 GB.

Example on a folder inside...

Properties window of a folder with a redacted name. The size of the folder is 379 MB, but the size on disk is 0 bytes.


Yet another situation where the "Size on Disk" property of a file or a folder may differ from its "Size" property is when you're using some sort of...

RAID (redundant array of independent disks) setup

In a RAID, a storage system is composed of multiple disks, for numerous reasons. There are six major standard levels of RAID. One reason why you might have a RAID is to secure your files so that even if a drive fails, a file that you stored on it is not lost. While the RAID 0 level does not conserve multiple copies of a file, being used mostly to distributes the contents of files between the drives to achieve higher read/write speeds, RAID 1 and above level setups do conserve its files: any file copied to that storage system will have a parity in each of its drives.

In a RAID 1 setup that is a mirrored copy in each of the drives, and so, when you look at the "size on disk" property, you will see that it is bigger, not only the cluster slack space, but also proportional to the amount of copies of your file that are being kept. Higher RAID levels use different algorithms to increase efficiency.

I'm not sure what RAID setup my organization uses, or how many drives are dedicated to each setup, but, right now, I have a folder that is 114 MiB, when its size on disk is 1.92 GiB.


Size is how big the files are. Example: a file might be 1 byte. Size on disk is how much space the file takes up on your hard drive or SSD. Example: if a filesystem has a 128 KiB cluster size, then that 1-byte file will take 1 cluster, which is 128 KiB, because that's the smallest data unit such a filesystem in this particular example I am making up to make the point can allocate. The point is: a filesystem cannot allocate less memory for a file than its cluster size. This means, on this example system where I hypothetically said it has a cluster size of 128 KiB, for that one single 1-byte file, you have (128 KiB - 1 byte) of wasted space. I'm not saying that's your cluster size; I'm just making the point.

Typical cluster sizes are groups of sectors of quantity power-of-2, where a sector might be 512 bytes (0.5 KiB). So, you can have a cluster made up of 1 sector, 2 sectors, 4 sectors...256 sectors, 512 sectors, etc. (quantity power-of-2). If the sector size is 0.5 KiB, again, which is common, then a 1-sector cluster is 0.5 KiB, a 2-sector cluster is 1 KiB, a 4-sector cluster is 2 KiB, an 8-sector cluster is 4 KiB, etc. 4 KiB is a pretty common sector size for many types of filesystems, I think, but exFAT, as one example, defaults to 128 KiB cluster size for larger drives. See the table by Microsoft at the end of my answer here. This larger cluster size means there is a lot more wasted space when you have lots of small files, but you get a slight speed increase. See the speed and disk usage plots I meticulously made, just below, to see the tradeoffs of cluster size vs speed and disk usage.

Let's look at a bigger example. From my comment here:

So, if you had 10000 files that were 1 byte each, that would be about 10000 x 8 KiB / 1024 = 78 MiB on an 8-KiB-cluster exFAT drive, and a ridiculous 10000 x 32 MiB/1024 = 312.5 GiB on a 32-MiB-cluster exFAT drive. Again, 4096 times higher.

Here are some plots I made to show size vs size on disk for a representative OS I have with ~1M files and 74 GB of data on an exFAT filesystem. I'm not saying that's your filesystem type, but the points and lessons remain and apply to other filesystem formats as well:

enter image description here

Read more here:

  1. My answer: Is it best to reformat the hard drive to exFAT using 512kb chunk, or smaller or bigger chunks?
  2. My website article where I first presented and explained the plots above: https://gabrielstaples.com/exfat-clusters/
  3. My full Python matplotlib/numpy plotting code is here: https://github.com/ElectricRCAircraftGuy/eRCaGuy_hello_world/blob/master/stack_exchange/format_exFAT_PLOTS.py
  • You state: "Ex: that 1 byte file might take 128 KiB if your cluster size is 128 KiB, as that's the smallest data unit your filesystem can allocate." As the thread opener did not mention his file system your assumption is wrong. A NTFS file system can very well use a cluster size of 4096 bytes. I guess that NTFS is more commonly used than exFat. Instead of focussing completely on exFat you should rather write about the differences in cluster slack when comparing NTFS to FAT-type file system or even a linux-based file systems like the RiserFS which does not seem to create slack.
    – r2d3
    Commented May 23, 2023 at 19:09
  • Does an Apple computer typically uses exFat for the operating system? I guess it's rather APFS or HFS.
    – r2d3
    Commented May 23, 2023 at 19:09
  • @r2d3, Apple is APFS. Old Apple is HFS+. I copied the data from an apple I'm wiping using a Linux Ubuntu 22.04 live USB, hence why I had to use exFAT. I don't use MacOS. I'm wiping it and installing Ubuntu 22.04. My goal with this answer is to contribute something that hasn't already been said, hence why I didn't cover what's already been covered. Producing those plots was a mini Master's thesis of effort--dozens of hours. Commented May 23, 2023 at 19:22
  • 1
    Aside from the possibility of a file being resident on an NTFS volume, as soon as clusters are allocated to a file the above seems correct and generally applicable to me. It also seems to me that any file system that addresses space in blocks / clusters or whatever you call them will to some degree suffer from space lost due to slack. Commented May 23, 2023 at 20:08
  • 1
    @r2d3, I didn't realize you thought I was assuming the OP's filesystem type was exFAT, or that their cluster size was 128 KiB. I'm not. I was just using those as examples. I've updated my answer. Commented May 23, 2023 at 21:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .