{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}{{ badge.label }} {{ badge.value }}
File and disk size conversion inputs
Enter one file, folder, volume, quota, or device size and keep its unit explicit.
Choose the notation needed for a report, purchase comparison, quota, or migration plan.
Use Decimal unless the source explicitly uses plain labels for binary values.
Choose the decision the headline should answer; every artifact remains byte-anchored.
{{ workflowFeedback }}
Zero is neutral. Use a measured or policy-approved percentage when available.
%
No rounding is neutral. Choose a cluster or extent size only for an allocation-aware estimate.
One is neutral. A representative file count makes small-file slack visible.
files
Use more decimals when reconciling large SI and IEC labels.
{{ ledgerExportStatus }}
UnitEquivalent valueBasisCopy
{{ row.label }}{{ row.value }}{{ row.basis }}
{{ chartExportStatus }}
{{ notesExportStatus }}
DecisionCurrent readingNext checkCopy
{{ 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.

Storage quantities that should not be confused
QuantityMeaningTypical cause of disagreement
Payload bytesLogical size of the files or dataCompression, sparse files, and hidden data
Raw capacityBytes named by a device, volume, or tierDecimal versus binary labels
Usable capacityRaw capacity after a planning reserveMetadata, snapshots, policy headroom, and working space
Allocated sizePayload rounded to storage allocation unitsMany 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.

  1. Enter Size, its source unit, and the unit needed for the converted result.
  2. 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.
  3. Set Sizing goal to pure conversion, raw-capacity analysis, or payload-to-store planning.
  4. 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.
  5. 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.

B=x×ffrom xconverted=Bfto Ballocated=n×a×Bna Brequired raw=Ballocated1r

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:

Decimal and IEC storage unit factors
FamilyExamplesFactor per step
DecimalKB, MB, GB, TB1000
IEC binaryKiB, MiB, GiB, TiB1024
Legacy binary plain labelsKB, MB, GB, TB interpreted in legacy mode1024

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: