Terms of Use For FixedByVonnie

By proceeding to access fixedByVonnie.com, you expressly acknowledge, and agree to, all of the following:

fixedByVonnie.com is a personal website and blog owned by Security Plus Pro LLC, which is being presented for informational purposes only. The views on this website are solely those of the website owner (and not those of any employer or of any professional associations affiliated with the website owner).  Any views expressed in this website and any information presented on this website, or in any of its blog entries, should not be relied on for any purpose whatsoever other than as the personal opinions of the website owner.  The website owner expressly disclaims any and all liability for any information presented on this site.  The owner of this website and its blog posts shall not be held liable, and shall be held harmless, for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.  The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action, from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so solely at your own risk.

What's the difference between my file size and the size on disk? - fixedByVonnie

What’s the difference between my file size and the size on disk?

Am I being presumptuous when I say that sometimes Windows is an extremely confusing operating system?

I’m not referring to the graphical user interface.  Anyone can point and click a mouse; I’m talking about the little things that just don’t seem to make any sense.

One of those little things revolves around the quirkiness of file sizes.

If you right click any file or folder in Windows and go to Properties you’ll see two seemingly contradictory attributes:

  • Size
  • Size on Disk

Sometimes these values match but other times they’re different.

As you can see below, I have a folder called Web which is where I store all my websites.  Windows is showing that the Size is 3.82 GBs but the Size on disk is 3.87 GBs.

Windows 8.1 File Size vs Size on Disk

So which one is it?


Microsoft’s Raymond Chen has a great technical explanation of the size disparity; however, it might be too abstruse for average users.  So I’ll give you the Vonnie translation.

Let’s say you created and saved and empty text file called “Nothingingness.txt”.

Even though there’s nothing in the file and the Size and Size on Disk properties show zero bytes, it still consumes space because Windows has to allocate negligible room for metadata such as:

  • File location
  • Creation Date
  • Permissions
  • The name of the file itself

To understand why there is sometimes a difference between the file size and the file size on disk we need to understand a little bit about the “lay-of-the-land” as it applies to hard drives.

Traditional spinning disk hard drives are segmented into concentric circles called tracks.  If you could visualize this it would look something like a bulls-eye from a dartboard.

A single “slice” of the dartboard “pie” gives you a sector.  It’s basically a way to section the hard drive so you can do something meaningful with the data on it.

A collection of sectors is called a cluster and this is the tiniest amount of disk space that can be used to hold a file. They typically range from 512 bytes to 32KB in size but the important thing to note is that the sizes are estimations and are always rounded up to nearest whole number of clusters.

This means if your hard drive is segmented into 512 byte clusters then any files smaller than 512 bytes will still take up the full 512 bytes on the disk.

To illustrate this point I created a new file and copied all 26 characters of the alphabet 20 times.  Since this is a plain text file with no formatting, spaces or anything like that, the actual size of the file is 520 bytes.

That’s because each ASCII character is exactly 1 byte so… 26 characters in the alphabet multiplied by 20 duplicates equals exactly 520.

Understanding the file size and file size on disk

Easy enough.

But notice that the Size on Disk shows 4,096 bytes.  Where the heck did that number come from?

The 4,096 is my cluster size also called the allocation unit.

This is how you can find your cluster size:

In Windows 8 you can press Windows Key + x + a to open the Command prompt and type:


(Windows 7 and Vista users can just click the windows icon in the lower left corner of the screen and then type the same command)  .

When the diagnostic finishes, scroll down and look for the little line that reads:

bytes in each allocation unit

That is your cluster size in bytes.

Bytes in each allocation unit

In my example, you can see my cluster size is 4KB.  I just took 4,096 bytes and divided by 1,024 to get the number of bytes per kilobyte.

The computer is just rounding to the nearest factor of the cluster size: 4KB.

Let’s keep doubling the bytes of text in the file to see what that does to the size on disk.

File size on disk 2

520 * 2 = 1040

Alright let’s keep going.

File size on disk 3

1040 * 2 = 2080

Now we’ve almost closed the gap.  I’m going to double the alphabet one more time.

File size on disk 4

2080 * 2 = 4160.

Now since this is larger than the cluster size of 4096, Windows rounds up to the nearest factor of the cluster.

Notice how my Size on Disk value now shows the next multiple of the cluster size.  This is what happens to every file and folder on your computer and it’s why the Size and Size on Disk values sometimes don’t match.

So what’s the real size?

The actual size of the file in bytes is the Size value. In other words, my alphabet file example is exactly 4,160 bytes; therefore, someone would need at least 4,160 bytes of space of storage on their hard drive to view it.

Think of the other value as the amount of space you’ll reclaim by deleting the file.

In other words, if I delete alphabet-160-times.txt I’ll get back 8,192 bytes of hard drive space.  This is because the the smallest unit of data a hard drive can work with is the cluster and my file is consuming two blocks of 4,096.

I hope that makes sense.

This whole size vs size on disk thing is pretty confusing but it really all comes down to clusters.  Think of the cluster like a cubbyhole.  It doesn’t matter if you put something small like a shoe in the cubbyhole or a pillow that fills the entire hole.  The cubbyhole is still a fixed size.  I hate analogies when it comes to this sort of thing but that’s what’s happening on your computer.

Welcome to the wonderful world of bytes and clusters!

Sounds like a bad fruit smooth restaurant… oh well – I hope my article helped.


Connect with Vonnie on Twitter

Posted in Windows, Windows 7, Windows 8, Windows 8.1, Windows Vista Tagged with:
  • Gabriel Mohňanský

    i give you ***** – five stars

    • rAeviLmAn D

      I read
      i give you fuck – five stars

      • sparcboy

        There are 5 asterisks, not 4.

  • crystallized

    That makes a lot of sense, actually. As an IT student – and even before becoming one – this has boggled my mind for so many years. Thanks for the great explanation!

  • Joy

    Your explanation is really good!

  • Naveen Kumar Ch

    you are amazing …. thanks a lot for the crystal clear explanation

  • Shravan Sajjan

    Please help… An image size is shown as 5GB and size on disk as 0 …whereas the actual size may be just 5 or 6 MB

    • Zacky Ahmed

      Run chkdsk /r
      your hard drive is fucked

  • grg


  • Ashwin Carpenter

    thank you so much… very nice explanation… 🙂

  • Andrew

    What if the size on disk is smaller than the size? For example, I have a folder, where the size is 16.1 GB, but the size on disk is only 11.6 GB. According to this explanation, the size on disk should be bigger, not smaller.

    • johnny sk

      Exactly ! I too have so many files where the size on disk is low than size of file. I don’t get it though !

    • Daryl Lawton

      From what I can tell that is some mixture of hard-linking (where shortcuts are made rather than copying a file) and compression.

      • sparcboy

        Files stored on our storage arrays are slightly compressed and thus always smaller than the actual file size. I work with seismic data and it’s not uncommon to have a single file that’s 500gb, and some are over a terabyte. While not highly compressible, they are always smaller. So I use only the “Size” to confirm copying.

        • gerardmanvussat

          If you absolutely, positively need to ensure the integrity of copied files, size is not enough, it would be required to perform a checksum calculation as well, or use a dedicated file comparison tool. Of course, for files that big it adds a lot of overhead, but so many things can silently corrupt data that I’ve become somewhat paranoid about it…

    • You’re downloading something in that folder which is not completely downloaded yet.
      Suppose you’re downloading a file of 5 GB. 1 GB is downloaded and the rest is remaining. The file size, then, will be 5 GB and size on disk will be 1 GB

      • Zach

        My windows folder is doing that. I am not downloading anything. file size is like 19GB and the Size on disk is 13.5

        • Size on disk is the actual size while the file size is based upon the information provided by the developer of file. i.e. if a file size is 19 GB it means that according to the information stored in the file/folder, size should be 19 GB. While the size on disk (13.5 GB in your case) is the space occupied by that file/folder in hard disk drive.
          It means the folder is missing some files.

        • gerardmanvussat

          It’s most likely because some large files are compressed (they usually appear in blue color, and with a “C” in the Attributes column, or when checking the properties, and going to Advanced, the “Compress data…” option is checked) or “sparse” (a more obscure NTFS feature which some programs use – download managers and file sharing softwares for instance – but which is not easily accessible to the user, it simply de-allocates empty clusters, meaning that a large file with a lot of empty space will have a very small actual size). What “GameMaza Net” wrote above is wrong, very few file types have an embedded size information located in the header (some video formats for instance like MKV or WMV), and even then, the Explorer does not use this information to calculate the size of a folder. But if there a filesystem inconsistency can be the cause of a size discrepancy, if files have been deleted but still have a record in the MFT, or if the MFT is corrupted; a CHKDSK analysis can usually fix those inconsistencies, but it can result in the loss of the wrongly catalogued files, even though their actual data could still be recovered.

  • Paul “MacE” Payne

    Forgive me if this post is in the wrong section – its my first EVER post to a forum – if thats what this is lol – Obviously Im a newbie!!

    I have downloaded a game.
    Iv copied the game to my library which is a folder called ‘Games’ on another harddrive (D:).
    Now, when I goto the properties of the game saved in the Games library on my D: drive, the size on disk reads – 42,210,904 bytes.
    The copy of the game thats still in the original download folder on my C: drive reads a size on disk of – 42,210,304,000 bytes.
    Both copies of the game have a size of 42,210,290,402 bytes..
    Can someone please tell me if Im to keep pulling my hair out worrying that I am loosing data somewhere as the ‘size on disk’ readings r different or is this perfectly OK?
    Thanks in advance!

    • Carbon Cookies

      I’m not sure if you still need an answer to this question, since I’m 3 months late. The reason this probably happens is due to the disks having different allocation sizes. Open the command prompt as an administrator (On windows 10 this can be done by Windows key+x followed by a) and type “cd..” until you reach the drive (C:>) and type “chkdsk” await the result and at the bottom you’ll see “xxxx bytes in each allocation unit.” Once you do this for a drive (eg C) you’ll need to type “D:” and run “chkdsk” again. Compare the “xxxx bytes in each allocation unit.” Is it the same? Are they different? If so, by how much? If you don’t already do, you should defragment (by going into the start menu and typing “defragment”) and restart your computer at least once a week.

      • gerardmanvussat

        Quicker way to reach the partition’s root :
        42210299904 is a multiple of 4096 (or 4KB).
        42210304000 is a multiple of 8192 (or 8KB).
        In this particular case the waste of storage space is negligible : 4KB compared with 39GB is less than 0.0001%. However it can be a significant issue when a partition with a high cluster size (like 32K or 64K) contains a gazillion of very small files : for instance each 1KB file stored on a partition with a 64KB cluster size wastes 63KB which is 6300%.

  • yousef

    i’ve read an artical before about the same problem .. but that man said that u’ll have a waste equals the same space of the block or something like this so when u use 4kb u will lose 8kb from ur memory or something like that .. u know anything about it? 😀

  • Bokar


  • hrudai murari

    i am creating a notepad file with characters less than 696 bytes .so the problem is if the file size is less than 697 the size of the disk is 0,if there are more than 697 bytes size of the disk is 4KB like which explained above.can any one explain me why size of the disk is zero for 696 byte.


    • gerardmanvussat

      That’s because when a file’s contents + metadata (name, timestamps, attributes and whatnot) has a size inferior or equal to that of a MFT record, which is generally 1024 bytes, then the whole file’s contents can be written inside the MFT record itself. In this case, the name is short, so the metadata occupies little space, and the file’s contents can be as large as 697 bytes and stay in the MFT; such a file is said to be “resident” (if the file’s name was longer then less space would be available). As soon as the size exceeds what can be stored in the MFT, the whole file is written to one or more clusters in the data area and becomes “non-resident” (and once at least one cluster has been allocated, that file will not become “resident” again even if its size in shrinked enough so that it could fit again in the MFT record).
      By the way, there has been a change in behaviour between (I believe) Windows 7 and Windows 8 : until Windows 7 (which I still use), the “size on disk” for a “resident” file was displayed as equal to the size of one cluster. The new behaviour is perhaps more confusing for the general public but also more consistent.

  • Jareer Ahmed

    I have a same problem files are not more than 147 GB on drive but it is showing Occupied space is 344GB.

    Could you please help here to get the space back allocation unit is 64KB

    • gerardmanvussat

      You would have to move the files to another partition, preferably check that the copy was complete and flawless with something like WinMerge, then re-format the source partition with a standard 4KB cluster size, then move back the files… Some advanced partition managers might be able to change the cluster size in-place, but that’s a tricky operation, do a complete backup before attempting something like that.
      Alternatively, if the drive contains mostly large files (which won’t waste a significant amount of space) but also contains a particular folder with many small files, you could either move that folder to another partition with a small cluster size, or compress it as ZIP / RAR / 7Z, which will group all those small files into a single large archive, which will waste at most the size of one cluster (but obviously that’s not practical if that folder is modified often).