Why Your Drive Is Smaller Than the Box Said
A drive sold as 1 TB holds a trillion bytes, which is exactly what decimal terabytes mean, but a system counting in binary units reports that same capacity as roughly 0.91 TB. Nothing is missing. The manufacturer and the operating system are just counting in different bases, and the gap is about seven percent at gigabyte scale and larger above it. Getting this right matters for storage planning and transfer estimates.
Key takeaways
- Decimal units use powers of ten, binary units use powers of two, and they diverge by about seven percent at gigabyte scale.
- Storage manufacturers use decimal, so a drive isn't smaller than advertised, it's counted differently by the system.
- Connection speeds are in bits and file sizes in bytes, a factor of eight that catches people constantly.
- Transfer time is a file size divided by a rate, which needs unit algebra to compute in one line.
- Calculated transfer times are theoretical ceilings, since real transfers lose to overhead and shared bandwidth.
The decimal against binary split
Two systems for counting data, both correct, both in active use, which is the whole problem.
| Decimal unit | Bytes | Binary unit | Bytes |
|---|---|---|---|
| Kilobyte (KB) | 1,000 | Kibibyte (KiB) | 1,024 |
| Megabyte (MB) | 1,000,000 | Mebibyte (MiB) | 1,048,576 |
| Gigabyte (GB) | 1,000,000,000 | Gibibyte (GiB) | 1,073,741,824 |
| Terabyte (TB) | 10^12 | Tebibyte (TiB) | 2^40 |
The divergence compounds. About 2.4 percent at kilobyte scale, roughly 5 at megabyte, about 7.4 at gigabyte, and near 10 at terabyte. That's why a 1 TB drive shows as roughly 931 GiB when a system counts in binary and labels it "GB" anyway, which is the labelling sloppiness at the root of most confusion.
The honest position: the drive holds a trillion bytes, the manufacturer told the truth in decimal, and a binary-counting system reports fewer of its larger units. Nobody is cheating.
Why this matters in practice
Three situations where the base actually changes a decision rather than just an appearance.
Fitting data on a drive. Planning to put 950 GB of files on a "1 TB" drive that reports as 931 GiB means it won't fit, even though the numbers look fine at a glance. The seven-to-ten percent gap is exactly the margin people cut it to.
Memory against storage. RAM is typically counted in binary, storage increasingly in decimal, so comparing them directly without noting the base produces a mismatch that looks like an error.
Cloud and bandwidth billing. Providers vary in which base they bill and report in, and a large transfer or storage figure can differ by the same margin depending on the convention, which matters when it's metered.
Writing the unit you mean explicitly, gib against gb, and using a tool that distinguishes them is the whole fix. A natural language calculator for Mac that treats the two as different units catches the gap that a converter guessing at "GB" hides.
Bits against bytes, the factor of eight
The other data-math trap, and it's an order of magnitude larger than the base issue because a factor of eight dwarfs seven percent.
Connection speeds are quoted in bits per second. File sizes are measured in bytes. A byte is eight bits. So a connection advertised at 80 megabits per second delivers at most 10 megabytes per second, before any real-world losses.
The convention is usually a lowercase b for bits and uppercase B for bytes, Mb against MB, which is a distinction one keystroke wide and easy to miss. Mixing them produces an estimate off by eight, which is the difference between a transfer taking one hour and taking eight.
This is where unit algebra earns its place. A tool that knows mbps is megabits per second and a file is in megabytes does the factor-of-eight conversion inside the calculation, so you don't have to remember it.
Calculating transfer time
The most common data calculation developers run, and the one that most needs units to cancel.
18 gb / 40 mbps in minutesThe calculator recognises gigabytes divided by megabits per second, handles the bits-to-bytes factor, cancels the data dimension, and returns time. One line. Doing it by hand means converting gigabytes to gigabits, dividing by the rate, and converting seconds to minutes, with the factor of eight lurking in the middle.
A worked example a database migration might use:
db_size = 340 gb
link = 500 mbps
db_size / link in minutesTwo named inputs, one calculation, and a maintenance window estimate that updates if either figure changes. The calculator notepad app keeps the working visible, which matters when someone asks how you arrived at the window.
Read the result as a ceiling
Every calculated transfer time is a theoretical best case, and treating it as a firm estimate is a mistake.
Real transfers lose to several things the arithmetic ignores. Protocol overhead consumes a slice of raw bandwidth. Shared connections mean you rarely get the full advertised rate. Server-side limits cap throughput independently of your connection. And latency on small-file transfers dominates, since thousands of tiny files transfer far slower than one large file of the same total size.
A useful rule of thumb: budget meaningfully more than the calculated figure for anything that matters, and more still for many small files. The calculation tells you the floor on time, not the actual duration.
Other data calculations worth having
- Storage cost per unit.
120 usd / 4 tb in usd per gbto compare drive value across sizes. - Backup window.
1.2 tb / 25 mbps in hoursbefore scheduling an overnight backup. - Video bitrate to file size.
15 mbps * 90 min in gbto size a recording before capturing it. - Bandwidth per user.
1 gbps / 200 users in mbpsfor capacity planning. - Photo storage count.
256 gb / 4.5 mb in countto estimate how many images a card holds.
Each of these is a compound-unit calculation that a simple converter can't express, because each divides or multiplies units that have to cancel or combine. That's the specific capability that makes data math suited to a calculator with unit algebra rather than a conversion form.
Base conversion, briefly
Data work often touches number bases too, since sizes and addresses appear in hexadecimal and binary. Tools in this category typically convert between bases using the same conversion keyword as units, so 255 in hex or 0xFF in binary resolve directly.
Bitwise operations, shifts and masks, are supported in some tools and not others, so this is worth verifying against your actual need rather than assuming. A general calculator handles base conversion of values well and stops short of being a programmer's full bitwise environment, which is a reasonable scope line for Numi to draw.
Honest limits
- Transfer estimates are ceilings, not predictions, and real durations run higher.
- Base labelling is inconsistent industry-wide, so a figure labelled "GB" might be binary, and no tool can know which a source meant.
- Small-file overhead isn't modelled. The calculation assumes one contiguous transfer, and many small files behave very differently.
- Compression isn't accounted for. A transfer of compressible data moves faster than its uncompressed size suggests, which no size division captures.
- Bitwise depth varies. Base conversion is reliable; full bitwise operation support is not guaranteed.
None of these undermine the core use. They mean a Numi app document gives you a clean theoretical figure and an honest developer treats it as the optimistic bound, adding headroom for the losses the arithmetic can't see.
Frequently asked questions
Why is a 1 TB drive not actually 1 TB?
Manufacturers use decimal terabytes, where one terabyte is a trillion bytes, while many systems report binary tebibytes, where the same capacity reads as roughly 0.91 of the advertised figure. The drive holds what was promised in decimal terms; the system just counts it in binary units.
What is the difference between GB and GiB?
A gigabyte in decimal is a billion bytes using powers of ten. A gibibyte is 1,073,741,824 bytes using powers of two. They differ by about seven percent at that scale, widening at larger units, which is why storage and memory figures seem inconsistent.
How do you calculate download time from a connection speed?
Divide the file size by the connection speed, keeping bits and bytes straight, since speeds are in bits per second and files in bytes. Numi mac and similar tools cancel the shared dimension and return a time, which should be read as a theoretical best case.
Why is my download slower than my connection speed suggests?
The theoretical figure ignores protocol overhead, shared bandwidth, server limits, and the factor of eight between bits and bytes. An eight megabit connection delivers roughly one megabyte per second at best before any losses.
Does macOS report file sizes in decimal or binary?
Modern macOS reports storage in decimal units using powers of ten. This differs from some older systems and from tools reporting binary units, which is one reason the same file can appear to have two different sizes across applications.
