"File too large": 1953 KB fits a 2 MB limit, 2000 KB does not

If a form says 2 MB and you typed 2000 KB into a compressor, you are probably 14,942 bytes over. Measured today on a 24-megapixel photograph: 2000 KB produced a 2,014,942-byte file, and a limit of 2,000,000 bytes rejects it. The same photograph at 1953 KB produced 1,990,266 bytes and passed with 9,734 bytes to spare.

Nothing is broken. The compressor reads KB as 1,024 bytes, the form reads MB as 1,000,000 bytes, and the two are 4.8576% apart at that prefix. The round number is the one that fails, and it fails by almost exactly the size of that gap.

Test conditions: Chrome 155 on Windows 11, this site's compressor served locally, one file at a time through the normal file input. Sources: a 4000 × 6000 JPEG at 3,492,678 bytes and a 6000 × 9000 JPEG at 11,525,365 bytes. Eighteen runs in total, JPEG output, quality searched by the tool itself. The "bytes" column is the byte count of the file the tool handed back, read from the page's own report object, not recomputed from pixels or quality. Filesystem figures come from fsutil file layout, fsutil fsinfo ntfsinfo and du on drive C:, which reports 4,096-byte clusters.

One limit, two numbers, and the round one fails every time

Six limits, both readings of each. The left pair is what people type; the right pair is the same limit divided by 1024 and rounded down. Same source photograph, same encoder, same day.

The 2 MB row is the one worth keeping. On the 54-megapixel source, 2000 KB produced 2,047,725 bytes — 275 bytes inside the binary reading of 2 MB and 47,725 bytes outside the decimal one. A file can be inside one 2 MB limit and outside another by 47,725 bytes, and the only difference is which number the person who wrote the form had in mind. That same 54-megapixel file at 1953 KB came out at 1,994,944 bytes and passed both.

There is a limit to how often this bites, and it is worth stating because it stops the rule from becoming a superstition. At 10 MB the same 54-megapixel source could not fill the budget at all: at 9,765 KB the encoder ran out of quality headroom and stopped at 9,841,886 bytes at 95.31% quality, which is 158,114 bytes under 10,000,000 and therefore passes both readings. The unit gap matters most at small limits, where the encoder always spends the whole budget, and stops mattering once the picture runs out of pixels to trade.

The panel says 1.92 MB and the file is 2.01 MB

This is the trap that makes the whole thing feel unfair. After the 2000 KB run, the result panel on this site read "1.92 MB · 4000 × 6000 px · JPG". The file it handed back was 2,014,942 bytes. Both statements are true: 2,014,942 ÷ 1,048,576 = 1.92, and 2,014,942 ÷ 1,000,000 = 2.01.

So a reader who compares the panel to a form that says "max 2 MB" sees 1.92 against 2.00 and concludes the file will pass. It does not, if the form means 2,000,000 bytes. The panel is not lying and it is not rounding badly — it is answering in a different unit from the one the form is asking in. The same thing happens on the 54-megapixel file: the panel said "9.39 MB" for 9,841,886 bytes, which is 9.84 MB in decimal, and that one passed a 10 MB form only because the encoder had stopped early.

The only number that cannot be misread is the byte count, and every file manager exposes it somewhere: Windows puts it in parentheses after the rounded size, macOS shows a separate bytes figure in Get Info, and ls -l prints it as the fifth column. If you are within 5% of a limit, read that number.

The budget is a ceiling, which is why rounding down works

Rounding a limit down by up to 1,023 bytes would be reckless if the compressor treated its budget as an average. It does not. In all eighteen runs behind this page the output was at or under the tool's own target. The closest call was 77 bytes: the 54-megapixel file at 20 KB landed on 20,403 against a 20,480-byte budget. At the 2 MB limit the tightest margin was 275 bytes — 2,047,725 against 2,048,000 — and at 20 KB on the smaller source it was 139.

That is what makes the ÷1024 rule safe rather than merely lucky. The tool searches for the largest dimensions and highest quality that stay inside the ceiling, so any budget you set is a promise about the output, not a hope. Give it ⌊limit ÷ 1024⌋ KB and the file that comes back is under the limit in bytes — which is the only unit the form counts.

2.4% per prefix step, and where 4.8576% comes from

A binary prefix is ten doublings of 2: 1,024. A decimal prefix is three zeros: 1,000. One step of difference is 2.4%. The gap compounds with every step because each one multiplies again, which is why a kilobyte-level confusion is nearly harmless and a gigabyte-level one is not.

Both counters are in daily use, and you can watch a Microsoft tool pick the binary one on your own disk. fsutil fsinfo ntfsinfo C: on the machine used for this page reported 125,825,023 sectors at 512 bytes each, and labelled the total 60.0 GB. Multiply it out: 64,422,411,776 bytes. Divided by 1,073,741,824 that is 59.998 GB, so the label is right in its own base. In decimal it is 64.42 GB — the same disk, 4.42 GB apart, no rounding error anywhere.

The compressor on this site counts the same way, which is why its result panel called the 3,492,678-byte source "3.33 MB" while a decimal form would call it 3.49 MB. When you type 2000 into its KB box, the budget it computes is 2,048,000 bytes and the page's own report object returns exactly that. So the chain is: your file manager counts binary, the tool you shrank the file with counts binary, and the form that rejects the result may well count decimal. Only the last one decides whether the upload succeeds.

The diagnostic: how far over the limit are you?

This is the part that separates a unit problem from a size problem, and it takes one division. Take the overshoot as a percentage of the limit.

Two worked cases. A 2,040,000-byte file against a 2,000,000-byte limit is 2.0% over — inside the band, and the fix is one digit in the KB box: type 1953. A 2,600,000-byte file against the same limit is 30% over — outside the band by a factor of six, and no amount of base-switching will help; the picture has to lose 600,000 bytes of real data, and the lever for that is the pixel budget, not the number in the box.

The band is also the reason two people with the same file get different answers. A 2,030,000-byte file passes a form that means 2,048,000 and fails one that means 2,000,000, and neither form is wrong. If you have been told "it worked on the other site", this is usually why.

The file has a second size, and it rounds up to 4,096

Everything above compares content bytes. Windows also reports an allocation, the space the volume actually gave the file, and it rounds up to a whole cluster. On this machine a cluster is 4,096 bytes (fsutil fsinfo ntfsinfo: 4,096 bytes per cluster), and the rounding is visible file by file.

At icon sizes the rounding is not a detail, it is the dominant term. Three hundred copies of a real 2,048-byte PNG hold 614,400 bytes of picture and occupy 1,310,720 bytes on the volume — 2.13 times as much, measured with du on the folder. 300 × 4,096 accounts for 1,228,800 of that; the remaining 81,920 bytes are the folder's own index blocks, which is why an empty folder measures 0 and a one-file folder measures 4,096.

Which number a message used decides what fixes it. An upload form compares content bytes, so the 300 icons are 614 KB to it. A folder quota, a sync client's "this folder is too large", or a backup limit usually compares allocation, so the same folder is 1.25 MB and half of that is empty space at the end of clusters. Compressing those icons further shrinks both numbers, but the 2× overhead stays — at 2,048 bytes a file, the only way to halve the allocation is to get each file under 448 bytes, where it stops touching a cluster at all.

Zipping it costs 115 bytes a file and buys 0.64%

The other common response to "file too large" is to put the folder in a ZIP and send that. On photographs it does close to nothing, and in the default store mode it makes the archive bigger.

A JPEG's pixel data is already entropy-coded, so a second general-purpose compressor has nothing left to find. The 0.64% that deflate did recover is the part of a photograph that is not entropy-coded: EXIF, ICC profiles, thumbnails, and the padding at the end of blocks. If you need 15% off a folder of photographs, the ZIP cannot give it to you — the pixels have to go. Re-encoding at a smaller budget is the only lever, and it is the same lever whether the limit is counted in either base.

Questions this page gets

Why does 2000 KB fail a 2 MB limit?

Because 2000 × 1,024 = 2,048,000 bytes to the compressor and 2 × 1,000,000 = 2,000,000 to the form. Measured: the 24-megapixel photograph came out at 2,014,942 bytes at 2000 KB and 1,990,266 bytes at 1953 KB. The second one passes by 9,734 bytes.

Is a KB 1,000 or 1,024 bytes?

Both definitions are current. SI says kilo is 1,000; IEC reserves KiB for 1,024 and most software ignores that distinction when it writes KB. What matters is that you cannot see which one a form used, so aim at the smaller number. If you assumed wrong you gave up 4.86% of the budget, which is 4,857,600 bytes on a 100 MB limit and 48,576 bytes on a 1 MB one.

My file is 40 MB and the limit is 5 MB. Is this a unit problem?

No. The base can only explain 4.8576% of a 5 MB limit — 242,880 bytes. You are 35 MB over, about 700%. That file needs to lose 87.5% of its bytes, which is a re-encode, not a re-count. The measured budgets for that are on 300 KB and 500 KB, both of which state the pixel count you end up with.

Windows says my file is 9.53 MB and a 10 MB form rejects it. Which number is wrong?

9,999,360 bytes is 9.53 MB divided by 1,048,576 and 10.0 MB divided by 1,000,000, so neither number is wrong and the file sits on both sides of a 10 MB line. If the form still rejects it, it is not counting content bytes: it is counting the request body, which can be a third larger than the file. That mechanism is measured on the base64 page.

Does this apply to a 25 MB email attachment limit?

It applies to any limit expressed in MB, and the band is the same 4.8576%: 1,214,400 bytes at 25 MB. But the encoder matters more than the base at that size. A 54-megapixel photograph cannot fill a 10 MB budget at all — it stopped at 9,841,886 bytes and 95.31% quality — so at 25 MB it would pass both readings untouched. Check whether the file is anywhere near the limit before you convert anything.

What if the limit is in KB, not MB?

Then the band is 2.4%, and it is small enough that the round number usually works. 20 KB gives 20,341 bytes against a 20,000-byte limit — 341 bytes over, which fails, but barely. The measured fix is 19 KB, which came out at 18,991 bytes.

If the number you are fighting is the picture's pixel count rather than its bytes, the budgets are measured per target: 300 KB holds 4.84 megapixels, 500 KB holds 8.41, and 1 MB keeps 19.75 megapixels whole. Each page lists the byte value to type for a strict decimal limit as well.

And if the limit is a published rule rather than a developer's default — passport photos, visa portals, civil-service applications — those are read line by line on the portal requirements page, with the source URL and the date each was read. The four different kinds of limit that produce this message are separated on the triage page.