Human-Readable Sizes: How Byte Formatters Pick Their Words

Every file manager, terminal, and upload dialog makes the same quiet decision hundreds of times a day: how to say a number of bytes in words. 1536 becomes "1.5 KiB" or "1.54 KB" depending on the house rules — and those rules (best-fit unit selection, rounding, trimming) are worth knowing explicitly: they are the difference between an interface that informs and one that misleads.

Why raw bytes make bad interfaces

APIs return byte counts because bytes are exact: "size": 1536 carries no ambiguity. People do not estimate in digits; they estimate in magnitudes. Show a user 1073741824 bytes and 1083741824 bytes and they see two indistinguishable walls of digits; show 1.07 GB and 1.08 GB and the difference is legible at a glance. Formatting trades exactness for comparability, which is the trade an interface should make, as long as the exact value stays recoverable.

You see the result everywhere: ls -lh, du -h, file-manager status bars, download progress, storage settings pages, build-output summaries — all running some flavour of the same tiny algorithm.

The best-fit algorithm

Best-fit selection walks a unit ladder and stops at the largest unit that keeps the leading number at or above 1. Pseudocode for the whole thing fits in a paragraph: start at bytes; while the value is at least the step factor and a bigger unit exists, divide by the step factor and step up. That is all.

The ladder you climb depends on the convention. The SI ladder steps by 1,000 (B, KB, MB, GB, TB…); the IEC ladder steps by 1,024 (B, KiB, MiB, GiB, TiB…). The same input can therefore exit the ladder at different heights: 1,000 bytes is already "1 KB" in SI but still plain bytes in IEC until 1,024. For why the two ladders exist at all — and the famous "1 TB drive shows 931" arithmetic — see KB vs KiB: Why Your Drive Looks Smaller Than Advertised; this article stays on the formatting side.

Rounding: two decimals and the trailing-zero trim

After unit selection, the value needs shaping. The common choices: round to two decimal places, then trim trailing zeros so 1.50 prints as 1.5 and 2.00 prints as 2. Two decimals is the sweet spot for small values — 1.54 KB preserves more information than 2 KB — while large magnitudes usually collapse to one decimal or none, because "931.32 GB" implies a precision nobody needs on a settings page.

Trimming matters more than it sounds. A formatter that prints "2.00 KiB" wastes attention on zeros that carry no information, and readability was the whole point. But trimming must never round so aggressively that the display misleads: 1,999 bytes printed as "2 KB" is a rounding artefact, not an error, which is why audit-grade output pairs the formatted string with the exact count.

Formatting the same number two ways

Take 1,536 bytes — the canonical test case, because it is exactly 1.5 KiB and awkwardly 1.536 KB. Under SI rules: 1536 ÷ 1,000 → 1.536 → "1.54 KB". Under IEC rules: 1536 ÷ 1,024 → exactly 1.5 → "1.5 KiB". Both are correct; they answer slightly different questions. A good formatter shows both when the audience is technical, because the discrepancy itself is information — two tools that disagree by 2.4% per step will disagree about your disk, your download, and your quota.

The same input also stress-tests the edge cases: 999 bytes must stay "999 B" (never "1.00 KB"), zero must format without dividing by zero, and values past the top of the ladder must stop at the largest defined unit. A formatter that survives 0, 999, 1,000, 1,024, and a few large numbers is most of the way to production quality.

House rules worth adopting

Pick one convention per codebase and label it — IEC units (KiB, MiB) whenever the math divides by 1,024, SI units when it divides by 1,000. Keep the raw bytes adjacent to the formatted string in anything debuggable: logs, API responses, tooltips. Round to two decimals for small values, fewer for large ones. And never let a formatter be the only place the number exists — a size the user cannot verify is a size they cannot trust.

Try it yourself

The Byte Size Formatter implements exactly the algorithm above: paste any byte count and get the SI and IEC best-fit strings side by side, with factors and the exact value shown so rounding is never a black box. Feed it the edge cases — 0, 999, 1,000, 1,024, 1,536, 1,048,576 — and watch the unit boundaries move. For explicit unit-to-unit conversion when you already know the target unit, use the Data Unit Converter; to see the powers of two the IEC ladder is built on, the Binary Converter shows base-2 place values directly.