TB vs TiB Conversion Chart: Every Drive Size

A 20 TB drive that shows up as 18.19 is not defective, mislabelled or short. It contains exactly 20,000,000,000,000 bytes, which is what was sold. One tebibyte is 1,099,511,627,776 bytes, so those same bytes divide out to 18.19 TiB, and the ratio between the two units is a fixed 0.909495. Every capacity you will ever see reads 9.05 percent smaller once it is counted in binary. That single number explains almost every question that starts with "where did my space go".

Below is the full conversion table for every capacity a drive is sold at, then the same arithmetic for GB and MB, then what an array reports once parity is taken out, then the other overheads that stack on top of the conversion. Bookmark the first table. It is the one you will come back for.

What is the exact conversion from TB to TiB?

A terabyte is 10^12 bytes and a tebibyte is 2^40 bytes. Drive makers, networking equipment, and the International System of Units all use the decimal prefix, where kilo means a thousand, mega means a million, giga means a thousand million and tera means a million million. Operating system kernels, memory sizing and most filesystem tooling count in binary, because addressing hardware in powers of two is what the hardware does.

Both are correct and both are precise. The confusion arrives entirely from labelling: the binary units have had their own names and symbols since 1998, KiB, MiB, GiB and TiB, and a great deal of software still divides by 1,024 and then prints the decimal letters anyway. When a piece of software shows you "18.2 TB" for a 20 TB drive, it has done the binary division and written the wrong unit on the answer.

Every row is the same quantity of bytes expressed three ways. "Apparent shortfall" is the difference between the decimal figure on the label and the binary figure your operating system prints, which is always 9.05 percent of the label figure. Nothing in this table is an estimate: multiply the label figure by 0.909495 and you get the TiB column exactly.

Read the last column as a sanity check rather than as a loss. A 20 TB WD Red Pro shows a 1.81 TB apparent shortfall, a 8 TB IronWolf shows 0.72 TB, and a 24 TB Red Pro shows 2.17 TB. If the gap you are looking at is close to 9.1 percent of the label capacity, the conversion explains all of it and you can stop investigating. If the gap is much larger, the cause is parity, filesystem overhead or a partition that was not expanded, and the later sections deal with each of those in turn.

Why does the discrepancy exist at all?

Two industries picked different bases before either of them was big enough to care, and neither has been able to change since. Storage is sold by the byte and marketed in the same decimal prefixes as every other physical quantity: a 500 metre reel of cable is 500 metres, and a 500 GB drive is 500 thousand million bytes. Memory, in contrast, is physically addressed in powers of two, because an address bus with n lines reaches exactly 2^n locations. A memory chip that is not a power of two is a chip with wasted address space.

Early computing borrowed the decimal prefixes for those binary quantities, since 1,024 is close enough to 1,000 that nobody minded a 2.4 percent slip. The slip compounds with every prefix. At the kilo step it is 2.4 percent, at mega it is 4.86, at giga 7.37, and by tera it is 9.05 percent, which is large enough that a buyer notices it on the drive they just paid for.

The gap compounds at every prefix step, which is why nobody argued about it in the floppy disk era and everybody argues about it now. Ratio is decimal bytes divided by binary bytes, so multiply a decimal figure by the ratio to get the binary one.

The two percentages are not the same number, and this catches people out. Going from decimal to binary loses 9.05 percent. Going from binary back to decimal gains 9.95 percent. That is the ordinary asymmetry of percentages: a fall of 9.05 percent is undone by a rise of 9.95 percent, not by a rise of 9.05. If you are trying to work out how many decimal terabytes to buy in order to end up with a target number of tebibytes, multiply by 1.099512, not by 1.0905.

What is the GB to GiB and MB to MiB conversion?

The same arithmetic one and two steps down the ladder, which is where you meet it on SSDs, cache drives, system volumes and memory cards. One GB is 1,000,000,000 bytes and one GiB is 1,073,741,824 bytes, so a decimal figure reads 6.87 percent smaller in binary. A 1 TB SSD formats out at roughly 931 GiB, which is why the number 931 appears so often in forum posts from people who think they were shorted 69 GB.

Note the 1,024 GB row. It exists because some products are genuinely sized in binary units and then labelled in decimal ones, which is the reverse of the usual mistake. Memory modules are the honest case: a 16 GB DIMM really does hold 16 GiB, because memory is addressed in powers of two.

Transfer rates are the one place where the decimal reading is nearly always the right one. A drive rated at 250 MB/s means 250 million bytes per second, and a gigabit link carries 1,000 million bits per second, which is why its real ceiling is about 113 MB/s rather than 125.

Which systems report decimal and which report binary?

Knowing which convention you are reading is half of not being confused. The same drive will show three different numbers on three different machines, and all three are correct readings of the same byte count.

Figures in the last column are before any partitioning or filesystem overhead, so they are the raw device size as each tool reports it. Small differences between tools showing the same binary value come from rounding at one or two decimal places.

The awkward entries are the NAS interfaces. Synology DSM and QNAP QTS both do the binary division and print the letters TB, so a NAS is the most likely place for a buyer to conclude they have been sold short. It is also the place where a second deduction, parity, is happening at the same time, which makes the total look worse than either effect alone.

What does a RAID array actually report?

Parity is subtracted first, in decimal, and the unit conversion happens afterwards on the result. The order does not change the answer, but doing it in that order makes the arithmetic easy to check. Four 8 TB drives in RAID 5 hold 32 TB raw, give up one drive to parity for 24 TB usable, and that 24 TB is reported by the NAS as 21.83 TiB. If you expected 32 and see 21.83, then 8 of the missing terabytes are parity and the remaining 2.17 is the base conversion.

Usable capacity is computed with the same engine behind the RAID capacity calculator. With identical drives, SHR is exactly RAID 5 and SHR-2 is exactly RAID 6, which is why those rows are combined. For any other drive set, including mixed sizes, run it through the calculator rather than interpolating from this table.

Two rows in that table are worth staring at. Eight 20 TB drives under RAIDZ2 hold 160 TB raw and report 109.1 TiB, a gap of over 50 TB from the number on the invoice, and every terabyte of that gap is accounted for by two things you chose: two drives of parity and the base 2 conversion. Compare that with the 4 x 8 TB rows, where the same two effects are visible but small enough that people rarely query them. The bigger the array, the more the gap looks like a problem and the less it actually is.

What else eats capacity after the conversion?

The unit conversion is the largest single deduction, but it is not the only one. Partitioning, filesystem metadata, reserved blocks and copy-on-write slop all take a further cut, and they stack multiplicatively rather than adding up. Here is the whole chain applied to one 20 TB drive, so you can see where a figure like "17.5 TiB free" comes from.

Overhead percentages are typical published defaults, not measurements, and they vary by filesystem and by how the volume was created. ext4 reserved blocks default to 5 percent and can be lowered with tune2fs. ZFS slop space is roughly one part in 32 of the pool. The final row is advice rather than an overhead: a copy-on-write pool kept above 80 to 90 percent full fragments badly and slows down.

The honest bottom line for a single 20 TB drive is that it reads 18.19 TiB before you do anything, roughly 17.5 TiB once a filesystem is on it, and about 14.61 TiB of space you should actually plan to fill. None of that is capacity anyone took from you. The first deduction is arithmetic, the second is the cost of having a filesystem at all, and the third is a performance decision you can override if you want to.

What does the conversion cost you in money?

Nothing, because you get every byte you paid for. It does change the number you should use when comparing prices, though, and it is worth doing that comparison once so you know which figure you are looking at. A WD Red Pro 20TB NAS HDD (WD202KFGX) at $836.99 is $41.85 per decimal terabyte and $46.01 per binary tebibyte. Both figures are true. They are just answers to different questions.

Use the decimal figure when comparing drives against each other, because that is the unit every drive is sold in and it keeps the comparison clean. Use the binary figure when you are working backwards from a capacity target you have measured on an existing system, because the number you measured came out of a tool that counted in binary. Mixing the two is how people end up buying a drive that turns out to be nine percent smaller than the gap they were trying to fill. Our cost per terabyte chart uses decimal throughout and says so on every column.

How do I convert quickly without a calculator?

Three approximations that are close enough for planning and one exact method for when it matters.

• Subtract a tenth, then add a bit back. Take 10 percent off the decimal figure and add roughly one percent of the result. 20 TB minus 2 is 18, plus 0.19 is 18.19. This is accurate to two decimal places at every size in the table above.
• Multiply by 0.91. Fast, and wrong by less than 0.06 percent, which at 20 TB is about 10 GB. Fine for deciding what to buy, not fine for a capacity plan you will be held to.
• Going the other way, add 10 percent. If you need 10 TiB of usable space, buy about 11 TB decimal. The exact multiplier is 1.099512.
• Exactly: TiB equals TB times 0.909495, and TB equals TiB times 1.099512. Those two constants are 10^12 divided by 2^40 and its reciprocal, and they never change.

If you are sizing an array rather than a single drive, do not try to hold all of this in your head at once. Put the drive sizes into the RAID capacity calculator, which shows usable capacity in both units for every layout on the same drives, including mixed drive sizes and including SHR next to RAIDZ. The usable capacity chart has the same figures precomputed if you would rather look them up than type them in.

Does the same confusion apply to network speeds?

It applies, and it is worse, because networking mixes bits with bytes on top of the base problem. A gigabit link carries 1,000,000,000 bits per second, which is 125,000,000 bytes, and after Ethernet framing and TCP overhead the real ceiling is about 113 MB/s. Networking has always used decimal prefixes and always measured in bits, so a "1 gigabit" connection is genuinely a thousand million bits and not 2^30 of them.

That is why a single 7200 rpm drive, which sustains 150 to 260 MB/s on sequential transfers, already saturates gigabit on its own. Multi-gigabit ceilings work out at roughly 280 MB/s for 2.5GbE, 560 MB/s for 5GbE and 1,100 MB/s for 10GbE. If you are deciding whether faster networking is worth the switch, see 2.5GbE against 10GbE, which works through what a mechanical array can actually feed.

One place the distinction genuinely costs money: backup target sizing. If you size a backup destination from a binary figure you read on the source system and then shop for drives in decimal, you will buy a target that is very slightly too small, discover it at the end of the first full run, and have to buy again. Size the target in decimal TB with 20 percent of headroom on top, using the backup sizing calculator, and the problem disappears.

Related reading

• Usable capacity chart for both units at every bay count and drive size
• RAID level comparison chart for what each layout costs in parity before the conversion
• RAID capacity calculator for your own drive set, including mixed sizes
• How to choose NAS drives for CMR, workload ratings and what to buy
• Cost per terabyte chart for the price comparison in consistent decimal units
• 3-2-1 backup rule guide because parity is not a backup at either base