File and Disk Size Converter

Size:

Enter a non-negative capacity and choose the source unit, for example 1 TB or 931.323 GiB.

Convert to:

Choose the unit you want to quote first; tables keep decimal and IEC views available.

KB/MB/GB label basis:

Use decimal for vendor labels; use legacy binary only when KB means 1024 bytes.

Sizing goal:

Pick Convert only, Raw to usable, or Payload to raw before reading fit guidance.

Reserve / metadata overhead: {{ formattedReservePercent }}

Use 0 to 30 percent; the value updates usable capacity, raw payload targets, the scale surface, and fit checks.

Workload profile:

Pick a profile for a realistic starting point, or Custom to keep manual assumptions.

Allocation unit:

Choose no rounding, 512 B, 4 KiB, 16 KiB, 64 KiB, or 1 MiB extents.

Estimated file count:

Enter 1 to 1,000,000,000 files; large counts magnify cluster slack.

files

Display precision:

Choose 2, 3, 4, or 6 decimal places for displayed values.

Unit	Raw value	Usable @ reserve	Interpretation	Copy
{{ row.unitLabel }}	{{ row.rawDisplay }}	{{ row.usableDisplay }}	{{ row.context }}

Scenario	Best readout	Why it matters	Copy
{{ row.scenario }}	{{ row.display }}	{{ row.note }}

Common storage tier	Raw OS view	Usable @ reserve	Payload copies	Status	Copy
{{ row.tierLabel }}	{{ row.rawOsView }}	{{ row.usableDisplay }}	{{ row.payloadCopiesDisplay }}	{{ row.status }}

Metric	Value	Copy
{{ row.label }}	{{ row.value }}

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Storage numbers often disagree because they answer different questions. A drive label may describe decimal bytes sold by a vendor, an operating-system report may show a binary count, and a migration plan may need space after metadata, snapshots, and file-allocation rounding. The arithmetic is simple only after those meanings are separated.

Decimal storage labels use powers of 1000. Binary storage labels use powers of 1024 and are clearest with IEC prefixes such as KiB, MiB, GiB, and TiB. Older software can still print GB or TB while using binary math, so a plain label is not always enough to identify the byte count.

Common storage size labels and interpretation checks
Reading	Common source	What it usually means
GB or TB on a product label	Drives, memory cards, media, cloud quota sheets, and purchase specs.	Decimal powers of 1000 unless the source says otherwise.
GiB or TiB	Technical storage reports and tools that spell out IEC units.	Binary powers of 1024 with an explicit suffix.
Plain GB or TB from older software	Legacy operating-system dialogs and older admin reports.	May be binary math shown with a decimal-looking label.
Size on disk	Folder properties, file-system reports, and backup checks.	Payload plus allocation rounding, metadata, and other storage overhead.

A storage capacity path from label conversion to bytes, reserve, allocation slack, and a fit tier

The familiar 1 TB drive that appears as about 931 GiB is normally a label conversion, not missing data. One trillion decimal bytes divided by 1024³ produces the smaller-looking binary number. A different problem begins after the byte count is known: file systems reserve space, files may round up to allocation units, and storage tiers need enough usable capacity for the modeled payload.

Planning errors often come from mixing those problems together. A folder with a few large virtual-machine images may have little allocation slack, while an archive with hundreds of thousands of small files can consume noticeably more space on disk than its payload byte total suggests. A reserve percentage can be intentional headroom, not evidence of a failing disk.

Unit math can produce a planning estimate, but it cannot inspect a real volume. Compression, sparse files, snapshots, deduplication, hidden files, permissions, corrupted metadata, and storage-controller behavior can all change what an operating system reports. Treat the converted byte count as the starting point, then verify the real storage system before purchase, migration, or incident decisions.

How to Use This Tool:

Start with the size label you have, then choose how that number should be interpreted before reading capacity and fit results.

Enter Size and choose the source unit. Negative values are treated as 0, so enter a positive value when storage-fit guidance matters.
Set Convert to for the headline conversion. Conversion Matrix still shows every supported unit from B through EB and KiB through EiB.
Choose KB/MB/GB label basis. Use Decimal disk labels for vendor labels, media capacities, quotas, and purchase specs. Use Legacy binary labels only when the source clearly uses plain labels for 1024-step values.
Explicit IEC units such as GiB and TiB stay binary even when the plain-label basis changes.
Pick Sizing goal. Pure unit conversion centers on the target unit, Entered size is raw capacity shows usable capacity after reserve, and Entered size is payload to store estimates raw capacity needed for that payload.
Set Reserve / metadata overhead from 0% to 30%. Use it for metadata, snapshots, policy headroom, or a planning margin.
Choose a Workload profile for a starting assumption, then adjust Allocation unit and Estimated file count in Advanced when you know the file-system or workload shape.
Review Capacity Reality Check, Storage Fit Guide, Fit Ladder Chart, Allocation Footprint, and Sizing Inputs. If a fit row says Enter a payload above 0 B to evaluate storage fit., enter a positive size; if it says Short by, increase the tier or revisit reserve and allocation assumptions.

Interpreting Results:

Vendor decimal view is the comparison point for drive labels, media tiers, purchase sheets, and many quota displays. Strict IEC readout uses explicit binary labels such as GiB and TiB. Legacy OS shorthand shows binary values with older plain labels when that is how the source reported the size.

Usable if the entered size is raw capacity subtracts the reserve from a device or volume label. Raw capacity required to hold the payload runs the calculation in the other direction: it starts with the payload, adds allocation rounding when selected, then increases the raw requirement so the payload still fits after reserve is removed.

Slack space is estimated unused space from rounding average files up to the selected allocation unit.
Smallest common storage fit is the first built-in tier that clears the modeled payload after reserve and allocation assumptions.
Fit Ladder Chart is a planning view around the first fit or near miss, not a guarantee that a formatted volume will match exactly.

A first-fit tier can be a false comfort when the reserve, file count, or allocation unit is wrong. Check Sizing Inputs and Allocation Footprint before treating a Fits with result as a buy target.

Technical Details:

Byte count is the anchor for every storage conversion. Decimal units group bytes by powers of 1000, IEC units group bytes by powers of 1024, and legacy shorthand can display binary counts with plain KB, MB, GB, or TB labels. Converting to bytes first prevents the same label from silently changing meaning halfway through the calculation.

Reserve and allocation rounding model different storage effects. Reserve removes a percentage from raw capacity for metadata, snapshots, working headroom, or policy margin. Allocation rounding estimates how much space is consumed when each average file is stored in whole clusters, sectors, or extents. These estimates do not replace a file-system scan, but they expose why payload bytes and usable tier capacity can diverge.

Formula Core:

The formulas below use bytes as the shared unit. The reserve value is a fraction, so 5% is represented as 0.05.

\begin{array}{lcl} bytes & = & value \times unitMultiplier \\ targetValue & = & \frac{bytes}{targetUnitMultiplier} \\ usableBytes & = & bytes \times (1 - reserve) \\ allocatedPerFile & = & ⌈ \frac{bytes / fileCount}{allocationUnit} ⌉ \times allocationUnit \\ rawRequired & = & \frac{allocatedPerFile \times fileCount}{1 - reserve} \end{array}

For a decimal 1 TB input, the byte count is 1,000,000,000,000. Dividing by 1024³ gives about 931.323 GiB. With a 5% reserve, usable capacity becomes 950,000,000,000 bytes, or about 884.756 GiB.

Storage conversion and planning rules
Rule	Supported boundary	Effect
Plain decimal labels	KB through EB use the selected basis, normally powers of 1000.	Matches marketed storage labels when decimal basis is selected.
IEC labels	KiB through EiB always use powers of 1024.	Remains binary even when the plain-label basis changes.
Reserve	Accepted range is 0% to 30%.	Subtracts from raw capacity or increases required raw capacity for payload sizing.
Allocation unit	No rounding, 512 B, 4 KiB, 16 KiB, 64 KiB, or 1 MiB.	Rounds average file payload upward before total allocated bytes are estimated.
Estimated file count	Accepted range is 1 to 1,000,000,000 files.	Large counts make slack visible when allocation rounding is enabled.
Fit tiers	Built-in tiers run from 700 MB optical media through 60 TB shelf capacity.	Compares modeled allocated bytes with usable tier capacity after reserve.

The decimal-versus-IEC gap grows with each prefix step because 1000 and 1024 are applied repeatedly. One decimal terabyte is about 0.909 TiB, while one decimal petabyte is about 0.888 PiB. At larger scales, keeping the suffix and basis clear matters more in quotes, migration notes, and storage watermarks.

Common storage tiers are treated as decimal marketed sizes. Each tier's usable capacity is the tier byte count multiplied by 1 - reserve, and the fit status compares that usable capacity with modeled allocated bytes. When the entered size is 0 B, fit comparison is withheld because there is no payload to compare.

Worked Examples:

These examples separate label conversion from reserve, allocation rounding, and tier fit.

1 TB drive label

A drive listing entered as 1 TB with Decimal disk labels converts to about 931.323 GiB. With Entered size is raw capacity and a 5% reserve, Usable if the entered size is raw capacity is about 884.756 GiB. The first value explains the decimal-versus-IEC difference; the second includes planned reserve.

Photo library with many files

A 700 GB photo library using the Photo or media library profile assumes 50,000 files, 4 KiB clusters, and a 5% reserve. The average file is large enough that allocation slack is only about 6.4 MB, but the raw capacity required still rises to about 736.849 GB because reserve must remain after the payload is stored.

VM backup chain

A 2.4 TB VM backup chain with 48 files, 1 MiB extents, and a 10% reserve needs about 2.667 TB of raw capacity. Allocation rounding adds little because each file is large, while reserve drives most of the increase. A 2 TB tier remains short, so the fit guide should be read as a step-up signal.

Fit guide waiting for payload

A run with 0 B entered cannot recommend a fit tier. The storage rows show the prompt to enter a payload above 0 B. Enter a positive size, keep Sizing goal on Entered size is payload to store for destination planning, then compare Storage fit status for Fits with or Short by.

FAQ:

Why does a 1 TB drive show about 931 GiB?

A decimal terabyte is 1,000,000,000,000 bytes. A gibibyte is 1024³ bytes. Dividing the same byte count by the binary unit gives about 931.323 GiB, which is normal label conversion rather than missing space.

When should I use legacy binary labels?

Use Legacy binary labels only when the source report clearly uses plain KB, MB, GB, or TB for powers of 1024. For drive labels, media labels, purchase specs, and quotas, Decimal disk labels is usually the right basis.

Does reserve mean the disk is unhealthy?

No. Reserve / metadata overhead is a planning allowance for metadata, snapshots, working headroom, or safety margin. It is separate from hardware health, bad-sector reports, SMART status, and storage-controller diagnostics.

Why does file count affect the on-disk estimate?

When allocation rounding is enabled, each average file is rounded up to the selected allocation unit. Many small files can add visible slack, especially with 4 KiB or larger units.

What should I do when a storage tier is short?

Check reserve, allocation unit, and estimated file count first. If those assumptions are right, use a larger tier or treat Raw capacity required to hold the payload as the minimum raw target.

Why do fit rows wait when the size is 0 B?

A zero-byte input has no payload to compare against media, flash, and drive tiers. Enter a positive Size before using Storage Fit Guide or Fit Ladder Chart as planning evidence.

Glossary:

Byte: The base storage count used before values are grouped into larger units. One byte equals eight bits.
Decimal prefix: A prefix such as kilo, mega, giga, or tera that scales by powers of 1000.
IEC prefix: A binary prefix such as KiB, MiB, GiB, or TiB that scales by powers of 1024.
Reserve: A percentage removed from raw capacity for metadata, snapshots, headroom, or planning margin.
Allocation unit: The cluster, sector, or extent size used when estimating how file payloads round up on disk.
Slack space: The estimated difference between payload bytes and allocated bytes after allocation rounding.

References:

NIST Guide to the SI, Chapter 4, National Institute of Standards and Technology, updated August 18, 2025.
Definitions of the SI units: The binary prefixes, National Institute of Standards and Technology.
Correct disk space problems on NTFS volumes, Microsoft Learn, February 12, 2026.
Format method of the Win32_Volume class, Microsoft Learn, May 31, 2018.
How to configure Elasticsearch disk watermarks, Simplified Guide.