File and Disk Size Converter
Convert file and disk sizes between decimal and IEC units, then estimate usable capacity and allocation slack for storage planning.| Unit | Equivalent value | Basis | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.basis }} |
| Decision | Current reading | Next check | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.reading }} | {{ row.action }} |
A storage label is useful only when its byte basis is clear. Drive vendors, media capacities, and many quotas use decimal prefixes, while technical tools may report the same bytes with binary IEC prefixes. One trillion bytes is exactly 1 TB in decimal notation but about 931.323 GiB in binary notation.
| Quantity | Meaning | Typical cause of disagreement |
|---|---|---|
| Payload bytes | Logical size of the files or data | Compression, sparse files, and hidden data |
| Raw capacity | Bytes named by a device, volume, or tier | Decimal versus binary labels |
| Usable capacity | Raw capacity after a planning reserve | Metadata, snapshots, policy headroom, and working space |
| Allocated size | Payload rounded to storage allocation units | Many small files occupying whole clusters or extents |
Explicit IEC labels such as KiB, MiB, GiB, and TiB always use powers of 1024. Plain KB, MB, GB, and TB usually use powers of 1000, but older software sometimes applies binary math while displaying a plain label. That legacy shorthand must be identified before converting.
A capacity plan also needs workload shape. A handful of large backup images may waste little allocation space, whereas millions of small files can round up substantially. Reserve and allocation slack describe different effects and should not be combined into one unexplained percentage.
The result is a planning model, not a scan of a real disk. File-system metadata, snapshots, deduplication, compression, sparse allocation, deleted-but-open files, controller behavior, and storage faults can change observed available space. Verify the target system before a purchase, migration, or cleanup decision.
How to Use This Tool:
Start with the label you have, define its byte basis, and add reserve or allocation assumptions only when capacity planning needs them.
- Enter Size, its source unit, and the unit needed for the converted result.
- Choose the Plain-label basis. Use decimal for vendor and network-style labels; choose legacy binary only when the source clearly used 1024-step math with KB, MB, GB, or TB.
- Set Sizing goal to pure conversion, raw-capacity analysis, or payload-to-store planning.
- Enter a measured or approved Reserve and metadata percentage from 0% to 30%. Choose an Allocation unit and representative file count only when estimating slack.
- Check Capacity fit for the first built-in tier that holds the modeled allocated bytes after reserve. Increase precision when reconciling large SI and IEC values.
Interpreting Results:
Converted value is a unit change anchored to the same byte count. A smaller-looking GiB or TiB number does not by itself indicate missing capacity.
Allocated bytes adds modeled rounding slack. Required raw bytes then expands that allocation so the payload still fits after the selected reserve is removed. The first-fit tier uses the same reserve and allocation assumptions.
A fit result can be overconfident when average file size is not representative. Compare the model with a real file-count and size-on-disk report before selecting hardware or setting a quota.
Technical Details:
Bytes are the shared unit for every conversion. Decimal plain labels use factors of 1000; IEC labels use factors of 1024. Legacy binary mode changes only plain KB through EB labels, while explicit KiB through EiB remain binary.
Formula Core:
Let x be the entered size, ffrom and fto the source and destination unit factors, n the file count, a the allocation unit in bytes, and r the reserve fraction.
When no allocation rounding is selected, allocated bytes equal payload bytes. Otherwise the model divides payload bytes evenly across the estimated files, rounds that average file size up to a whole allocation unit, and multiplies by the file count. Slack equals allocated bytes minus payload bytes.
Usable capacity for an entered raw size is B × (1 − r). Each built-in storage tier is tested in the same way, and the first tier whose usable bytes are greater than or equal to allocated bytes is the first fit. A zero-byte payload has no fit tier.
Unit Core:
| Family | Examples | Factor per step |
|---|---|---|
| Decimal | KB, MB, GB, TB | 1000 |
| IEC binary | KiB, MiB, GiB, TiB | 1024 |
| Legacy binary plain labels | KB, MB, GB, TB interpreted in legacy mode | 1024 |
Accepted size values range from 0 to 1,000,000,000,000 in the selected unit. File count ranges from 1 to 1,000,000,000 whole files. Display precision affects presentation only and may be set to 2, 3, 4, or 6 decimal places.
Worked Examples:
Vendor 1 TB drive label
A decimal 1 TB label equals 1,000,000,000,000 bytes. Dividing by 10243 gives about 931.323 GiB. With a 10% reserve, the planning model treats 900,000,000,000 bytes as usable before any allocation or file-system-specific effects are considered.
References:
- NIST Guide to the SI, Chapter 4, National Institute of Standards and Technology.
- Prefixes for Binary Multiples, National Institute of Standards and Technology.
- How to configure Elasticsearch disk watermarks, Simplified Guide.