Why can’t Explorer decide what size a file is?

If you open Explorer and highlight a file whose size is a few kilobytes, you can find some file sizes where the Explorer Size column shows a size different from the value shown in the Details pane. What's the deal? Why can't Explorer decide what size a file is?

The two displays use different algorithms.

The values in the Size column are always given in kilobytes, regardless of the actual file size. File is 15 bytes? Show it in kilobytes. File is 2 gigabytes? Show it in kilobytes.

The value shown in the Size column is rounded up to the nearest kilobyte. Your 15-byte file shows up as 1KB. This has been the behavior since Explorer was first introduced back in Windows 95, Why? I don't know; the reasons may have been lost to the mists of time. Though I suspect one of the reasons is that you don't want a file to show up as 0KB unless it really is an empty file.

On the other hand, the value shown in the Details pane uses adaptive units: For a tiny file, it'll show bytes, but for a large file, it'll show megabytes or gigabytes or whatever. And the value is shown to three significant digits.

The result is that a file which is, say, 19465 bytes in size (19.0088 kilobytes) shows up in the Size column as 20KB, since the Size column rounds up. On the other hand, the Details pane shows 19.0KB since it displays the value to three significant digits.

It looks like Explorer can't make up its mind, and perhaps it can't, but the reason is that the two places on the screen which show the size round in different ways.

Comments (42)
  1. John says:

    As long as you don't switch to kibibytes…

  2. Gabe says:

    I was really hoping to learn the legacy backwards-compatibility reasons why Explorer's filesize formatting functions can't be made the same.

  3. Brian says:

    I was thinking the same as Gabe.  I really can't think of a reason the Size column can't be changed to use the same formula as the Details pane. I'm sure there's some obscure backwards compatibility reason, but I can't think of it.

    [Everything is a compatibility constraint. There may be an app that queries the file sizes from Explorer and relies on the current algorithm. (E.g., it does "atoi" of the string and assumes it's in KB.) -Raymond]
  4. Tom says:

    As was stated in the article, the reason it would be rounded up in the size column is to prevent apparantly 0-size files when there is actually data there. Assume a file is 2 bytes long, what size do you show in KB? Or would you prefer each row in the size pane to be in different units? That doesn't lend itself to easy scanning or sorting.

  5. configurator says:

    One day we'll have files so small we'll measure them in millibytes.

  6. Joshua says:

    It would have been more convenient had it rounded up to the next disk allocation unit size. Oh well.

  7. RobertWrayUK says:

    @Joshua, so the reported size of a file could change if you copied it to another disk/storage medium? Surely that's even more inconsistent?

  8. NB says:

    size column probably sticks to plain KBs and avoids the Details pane formula to give understandable sorting results when the user opts to sort it.

  9. mmh says:


    Also, think at what happens with sparse files.

  10. Anonymoose says:

    Why does the software industry think it can redefine words to mean what they want? A kilobyte is 1,000 bytes.

    Everything else your computer interacts with (including your network connection) is using the correct metric definitions for kilo, mega, giga, etc., A T1 line runs at 1.544 Mb/s (or 193 kB/s), this is 1,544,000 b/s (or 193,000 B/s) and that isn't really open to debate. Arguing that the prefixes magically mean something else when applied to data storage is ridiculous, its essentially arguging the following:

    193 kB/s * 1 s = 188.4765625 kB

  11. Joshua says:

    @mmh: exactly what it should do: block size * number of blocks allocated.

    [Note that this may give unexpected results: very small files occupy zero blocks. (Compressed and sparse files also occupy a number of blocks different from what the "file size" may suggest.) -Raymond]
  12. Humus says:

    A word means what the majority of users of that word use it as. If the majority of users think of kilobyte as 1024 bytes, then that's what the word means, regardless of what any kind of standard or dictionary says.

  13. bzakharin says:


    It's a bit like complaining that that a month cannot be divided neatly into weeks. We use incompatible units all the time. If you're going to complain that they have the same prefixes, we have three different tons, three different ounces. It's not really a transfer versus storage question. A kilobit by itself is still 1000 bits.

  14. Mason Wheeler says:

    @Anonymoose: Because the technology was invented in America, where we still understand the drawbacks of the Metric system.  It was created by scientists to describe measurements under laboratory conditions, and it works quite well for that, but not so well for measuring real-world conditions.  So we use measuring systems based on real-world conditions.

    A computer doesn't work in powers of 10, it works in powers of 2, and it addresses things in powers of 2, so we measure data volume in units based on powers of 2 instead of powers of 10.  Makes perfect sense to me.

  15. Leo Davidson says:

    @NB: How you display data does have to define how you sort data.

  16. Alex Grigoriev says:

    I wonder if there is an XKCD comic for that…

  17. David Walker says:

    I don't know about an XKCD comic, but of course there is this…

    'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'

    'That's a great deal to make one word mean,' Alice said in a thoughtful tone.

    'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'

  18. Ens says:

    Was the term invented in the US?  I can't find any information on who coined the kilobyte, actually, from a quick search.

    You've got the supposed "drawbacks" of the metric backwards, really.  The advantage of the US units is backwards-compatibility with many objects, manufacturing plants, and people who are denoted in or used to the US units, and that's really it.  "Laboratories" can in almost all cases use any units they choose (and often they invent their own units) so that is a wash.  The advantage of SI units is in making physics and engineering easier because of relatively easy unit conversions, plus cross-consistency in naming conventions, plus nowadays in most places people are used to SI units in the same way Americans are used to US units, and they have manufacturing processes, etc..

    And the advantage of a kilobyte meaning 1024 bytes is it matches laboratory conditions, whereas 1000 bytes has cross-consistency in naming conventions with other metric or SI units.

  19. WndSks says:

    It has the same problem with file counts, explorer just can't make up its mind: windowssucks.wordpress.com/…/a-file-in-the-details-pane-is-worth-two-in-the-statusbar

  20. fatcathu says:

    using unified size-unit in the size column is very useful when you look at them and want to detemine the relative sizes between files in a glance, you only need to compare the length of the number, then the first digit, you dont need to care about the unit since they are all the same. also useful for sorting.

  21. LR says:

    Joshua: "It would have been more convenient had it rounded up to the next disk allocation unit size. Oh well."

    Why? I like to see the file size, not some other value. The allocation unit is an completely unimportant implementation detail, most of the time (and it may be different on different volumes, like USB drives).

  22. Troll says:

    Well we did have column handlers so an app like Folder Size would show adaptive sizes in its own size column. But the seed of evil in some MS developer's mind decided to remove column handlers entirely to promote their half-baked replacement called the Property System which can't do several things that column handlers could! It's time the size column showed sizes using adaptive units. Take this as feedback for Windows 8 maybe. And folder sizes too IF USERS WANT THEM!!! Microsoft has no right to take away column handlers and not show folder sizes. BRING BACK COLUMN HANDLERS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Microsoft should be sued for removing a shell extension type.

  23. James Schend says:

    Wow. Time for the medication. (Good username though.)

  24. Klimax says:

    @Troll: Maybe its your own failure to understand.

  25. Brian says:

    Technically 1 Kilobyte is supposed to be 1000 bytes and has the suffix kB.  What people refer to as 1024 bytes is a Kibibyte and has the suffix KiB.  Not like anyone actually does that though.

  26. John says:

    @Troll:  Preach it, brother.  Don't forget about the friendly file times (e.g. "X minutes ago").  Somewhat ironically, file times revert back to their standard format (e.g. "hh:mm:ss") after a certain period of time.  So the more recently you've modified a file the less accurately you can tell when it was modified.  I think this has something to do with quantum computing.

  27. AK says:

    Joshua: a better option would be a separate optional column called Size on disk.

  28. It gets really silly in the case of hard drives.  Here's a quote from Western Digital's web site: "As used for storage capacity, one megabyte (MB) = one million bytes… As used for buffer or cache, one megabyte (MB) = 1,048,576 bytes".

  29. dave says:

    re: anonymoose

    Because there *wasn't* a software industry when the software industry redefined those words.

  30. djhayman says:

    I'll be very excited when my total RAM jumps from 4 GB to 4.294967296 GB for no reason! And who feels like buying a 2.147483648 GB flash drive?

    Everyone always forgets that memory capacity is almost always a power of 2.

  31. Voo says:

    @djhayman: While I basically agree, using flash drives as an example is.. unlucky, considering they've been using SI units for decades (handy 8% savings). Also it really depends on the area you're looking at, we can find examples for both.

  32. Worf says:

    Linux uses proper unambiguous units – and the tools do too. If you ask the tool for human compatible output, it divides by powers of 10 because when a user sees a 1.00MiB file (1.04MB), they're gonna say it's 1.04 megabytes when listed as bytes.

    And if you give me requirements, I'll interpret them with standard meanings. If software must load a 1MB file in 1 second, that means 1MB, not 1MiB. If I display it, I sometimes display both MiB and MB because sometimes a test vector makes one come out nice.

    Plus I like to be precise when dealing with other engineers. Ambiguity causes all sorts of issues. This can also mean I sometimes rewrite 1MB as .98MiB to tell others what I'm doing to remove ambiguity.

    Ye olde 1.44 MB floppy disk was a bastardization. It is 1440 kiB in size.

  33. Dmitry says:

    I wish there was a way to tell Explorer to show file size in Bytes, instead of KB. I am tired of having to open file Properties to see correct number.

  34. Ooh says:

    @Raymond: I can't believe you had to write this.

  35. GWO says:

    @Worf: Hmmm … you say linux uses "unambigous units".  Don't forget that the units that Linux uses on 'df' say, are part of what makes it non-POSIX by default.  This will print filesystem space in 1024 byte units – POSIX requires 512byte units (because POSIX's interfaces are every bit as old and crusty as Win32s.) You can set POSIXLY_CORRECT to get the "correct" 512byte block-counts.  Sadly POSIX_ME_HARDER no longer works.

  36. Ben says:

    @Ens: Actually, you're not quite understanding his rant. Americans are terrified of numbers: the imperial system is "better" and based on "the real world" because you can say "put that down a foot from the wall" instead of "put that down 30 centimetres from the wall". No human could possibly be used to using large numbers and decimals, so metric is only good for scientists. Also, Fahrenheit is better because there is a bigger numerical difference between different temperatures. These two conjectures are perfectly logical and do not contradict each other at all.

  37. Voo says:

    @Ben: Hey using a unit that's (well at least loosely historically) defined by the size of a dead king's feet is just way more stylish than anything else. But then my personal favorite are still ounces – I mean several different units under the same name? That's just plain genius :D

  38. Gabe says:

    Voo: There are many measurements with several different meanings. For example, a statute mile, nautical mile, and surveyor's mile are all different. A long ton, short ton, and metric ton are all weight measurements, while the volume of a ship has the same name (displacement ton, register ton, etc.) — not to mention its use for describing explosive power (e.g. megatons) or refrigeration (12,000BTU/h). A dram could be a weight or a volume. A gallon depends on what it's a gallon of (corn, wine, or ale).

    The foot story is likely apocryphal, though. It's far more likely that somebody came up with an inch unit and decided that 12 of them were nearly the length of a foot. The odds that somebody would have an actual foot that's 12 inches long would have been very small 1000 years ago.

    My favorite part about imperial units is that an ounce of gold really does weigh more than an ounce of feathers!

  39. configurator says:

    If very small files can occupy zero blocks, then why does a 1-byte file seem to use up 4 KB in its Properties under "Size on disk"?

    [See Just what is Size on Disk? -Raymond]
  40. 1 says:

    My 1-byte file is bigger than yours.

  41. GregM says:

    "If very small files can occupy zero blocks, then why does a 1-byte file seem to use up 4 KB in its Properties under "Size on disk"?"

    Because you have a sector size of 4KB, and size on disk is the number of sectors times the sector size?

Comments are closed.

Skip to main content