How KB Is Counted — and Why "Exactly 200 KB" Gets Rejected
Direct answer: a kilobyte has two definitions in the wild — 1 KB = 1,024 bytes (the binary tradition your phone and computer mostly use) and 1 KB = 1,000 bytes (the decimal definition many web developers use when they set a limit). A portal limit of "200 KB" can therefore mean 200,000 bytes or 204,800 bytes. A file sized to exactly fit one meaning is up to 4,800 bytes too big for the other — and portals reject by bytes, not by what your file manager displayed.
The two rulers
| Stated size | At 1 KB = 1,024 bytes | At 1 KB = 1,000 bytes | Difference |
|---|---|---|---|
| 20 KB | 20,480 bytes | 20,000 bytes | 480 bytes |
| 50 KB | 51,200 bytes | 50,000 bytes | 1,200 bytes |
| 100 KB | 102,400 bytes | 100,000 bytes | 2,400 bytes |
| 200 KB | 204,800 bytes | 200,000 bytes | 4,800 bytes |
| 500 KB | 512,000 bytes | 500,000 bytes | 12,000 bytes |
| 1 MB | 1,048,576 bytes | 1,000,000 bytes | 48,576 bytes |
The gap is 2.4% at every scale. It is small enough to be invisible in a file manager ("200 KB" looks like "200 KB") and large enough to fail a strict byte check. Strictly, the decimal unit has its own name — the SI kilobyte is 1,000 bytes, and 1,024 bytes is a "kibibyte" (KiB) — but almost nobody's upload form says KiB, which is exactly the problem.
Why you cannot just ask the portal
Application forms almost never state which counting the checker uses, and the person who wrote the form's help text often did not know either. The error message, when there is one, just says the file is too large. Testing both ways yourself — uploading, failing, shrinking blindly, uploading again — burns attempts on portals that limit retries.
The 5% fix
Aim about 5% under the stated cap: for a 200 KB limit, produce roughly 190 KB. That covers the full 2.4% counting gap in the worst direction, leaves room for the portal's own rounding, and costs you almost nothing in quality — at portal-upload sizes, 5% is a fraction of one quality step. This is why every KBExact ceiling defaults to cap − 5%, why the effective target is printed next to the field before you run the tool, and why every result report shows the achieved size in KB with the byte count behind it.
The same logic applies at the bottom of a window: if a portal demands at least 30 KB, landing at 31–32 KB is safer than landing at exactly 30.0. KBExact's window mode aims inside the window, not on its edges.
Questions
Why was my file rejected when it was exactly 200 KB?
Most likely the counting trap: your phone or computer measured 200 KB as 200 × 1,024 = 204,800 bytes, while the portal measured its limit as 200 × 1,000 = 200,000 bytes — or the reverse. The file did not change; the ruler did. A file that is exactly at the limit under one ruler is up to 2.4% over under the other.
Which counting is correct?
Both are in real use. Operating systems historically used 1 KB = 1,024 bytes (and modern ones are inconsistent — some show 1,000-based sizes in some places and 1,024-based in others). Many web portals compare raw byte counts against a round limit the developer chose with 1,000 in mind. You cannot know which ruler a given portal uses — which is why margin beats precision.
How much margin should I leave?
About 5% under the cap covers the full 2.4% counting gap with room to spare for rounding in the portal's own display. KBExact applies this margin by default on every ceiling and lets you switch it off.