For a while I spent every week wrestling with one number: how large a file the upload would actually accept. Looking at what was already on my drive, screenshots of a few hundred KB and movies of two or three GB, there was nothing in the middle like "exactly 10 MB" or "exactly 49 MB". I tried a movie file, renaming the extension and cutting it in half, and the size never came out to the round number I wanted; writing a script with dd gave me units that did not mean what I assumed. Then I switched to generating exactly the byte count I needed, and the task went from "find a file" to "calculate a file".
The root of the trouble: the unit you assume is not the unit it uses
In File Size Generator I can enter bytes, KB, MB or GB, down to the exact byte, with a filename and extension of my own. But before typing anything I have to settle one thing: two readings of the same "10 MB" differ by 485760 bytes.
The decimal reading is 1 MB = 1000000 bytes, the binary reading is 1 MiB = 1048576 bytes, which is 4.8576% larger. That percentage is fixed at the MB level and grows to 7.3741824% at GB. I worked out the common sizes and put them here, so when I need a boundary value later I just read the table.
| What you write | At 1000 per unit (bytes) | At 1024 per unit (bytes) | Difference (bytes) |
|---|---|---|---|
| 1 MB | 1000000 | 1048576 | 48576 |
| 10 MB | 10000000 | 10485760 | 485760 |
| 100 MB | 100000000 | 104857600 | 4857600 |
| 1 GB | 1000000000 | 1073741824 | 73741824 |
So when a requirement says "limit 10 MB", if the other side counts in 1024, a file of exactly 10000000 bytes gets accepted; conversely, if they count in 1000 and you generate 10485760 bytes, you are 485760 bytes over and get rejected. That is the direction I hit the first time. To test "the one byte just over the limit", I now confirm which convention the other side uses and then enter the byte count directly instead of MB.
One more cliche that I have genuinely been asked about: a drive sold as 1 TB shows about 931 in a system that divides by 1024, because 1000000000000 / 1073741824 is about 931.32. What is missing is the unit, not the capacity.
An all-zero file compresses to tens of KB, and that is not a high ratio
I once got muddled while testing compression: I generated a 10 MiB file, zipped it down to a dozen KB, and almost wrote "compression ratio of a thousand to one" in my conclusion. My mistake was filling it with zeros.
Compression works on repetition and pattern, not on size. All zeros are the most regular content there is, and DEFLATE-class algorithms top out around 1032 to 1 on it, meaning 10485760 bytes of zeros has a theoretical floor of about ten thousand bytes, and in practice it depends on block size and implementation. Change the fill pattern and the same 10 MiB may barely compress: with random data there is no pattern to exploit, the size after compression stays about the same, and it can even grow slightly because of the container header and checksums. Images and video, already heavily compressed, behave the same way; running them through again saves almost nothing.
So my rule is: decide first whether this test is about "size limit" or "compression behavior". For a limit, use random data, which gets closer to how a real file behaves; only when I specifically want to see how a compression algorithm handles low-entropy content do I use zeros. Reporting "our uploads can compress to tens of KB" based on zeros turns a property of the content into a claim about the pipeline. When I do want a real before-and-after, I run a batch of ordinary photos through Image Compressor and use the reduction in that table as the number I can quote.
"How big" a file is has two answers: logical size and actual usage
Another point that misled me: the byte count of a file and the space it actually occupies on disk can differ a lot.
If you only set the file length without writing data byte by byte, then on a filesystem that supports sparse allocation the logical size can be 10485760 while the data blocks actually used are close to zero. In that case ls -l and du disagree visibly. The time I hit this, I was filling a test partition according to plan, wrote to sparse files for a long while and it never filled up, because very little data ever landed on disk.
To tell which kind you have, my method is dumb but dependable: generate the file and watch the actual write time, or list the size with File Info Reader and check the logical size, then compare against the filesystem's own usage statistics. For a capacity test that needs the space genuinely occupied, you cannot trust the number in the listing alone.
As for the limits of generating in the browser, I go by what its documentation says: streaming generation, up to the hundreds of MB range; when I need a test file of several GB I go back to the local command line rather than push the browser.
What I test with each of the three fill modes
| Fill mode | Content traits | What I use it for | Not suitable for |
|---|---|---|---|
| Random data | Nearly incompressible, size close to a real file | Upload and download throttling, size limits, disk usage | The extreme behavior of a compression algorithm |
| Zero bytes | Most regular, compresses extremely well | Checking only whether an endpoint accepts by byte count | Compression ratio, real bandwidth |
| Repeating custom text | Predictable, readable content | Parsing, import and preview logic | Transfer behavior of high-entropy content |
One more note on testing throughput: a 100 MiB file finished uploading in 25 seconds, which is 104857600 divided by 25, or 4194304 bytes per second; to get megabits, multiply by 8 and divide by a million, about 33.6 Mbps. I once confused bytes and bits, the two meanings of B, and underestimated the link speed by a factor of eight.
Common questions
Q: I need "exactly 10 MB". What number do I enter?
Ask first whether they mean 1000 or 1024. For 1000, enter 10000000 bytes; for 1024, enter 10485760 bytes. The two differ by 485760 bytes, so picking one at random may not be what you want. When testing a limit I start at the smaller one and step up.
Q: Why does the generated file compress down to tens of KB?
Because you filled it with zeros or repeating text; what got compressed is the pattern, not the size. If you want it to resist compression, switch to random data.
Q: Is one file that just passes enough to test an upload limit?
No. I test at least three points: just under the limit, exactly at the limit, and one byte over. The middle one is where "less than or equal" and "less than" get mixed up, and a single normal-sized file will not reveal it.
Q: The logical size matches, so why did the disk not grow?
Probably sparse allocation: the length was set but the data never landed. Check with the filesystem's usage statistics instead of trusting the byte count in a listing.
Back to the original problem of "find a file that is exactly 10 MB". What I do now is confirm whether the other side means 1000 or 1024, generate by byte count, choose random data for the fill, verify the size once, and upload. It sounds like one extra calculation, but it removed the half hour of trial and error I used to spend every time.