Guides
Why a 1 TB drive shows about 931 GiB: checking the numbers with Convertix
Understand why a 1 TB drive can show 931 GiB, distinguish capacity from free space, and check byte calculations with Convertix Online.
Eternity Labs ·A 1 TB drive contains 1,000,000,000,000 bytes when its capacity uses decimal units. That same quantity is about 931.32 GiB in binary units. The smaller number does not, by itself, mean that files or storage have disappeared. Before investigating missing space, check whether you are comparing total capacity, a partition, or free space—and whether the labels mean GB or GiB.
This article uses a fictional troubleshooting example. I have a new external drive labeled 1 TB, and a storage utility reports a capacity close to 931. I want to understand the difference before deleting anything or changing the disk. The investigation below is an example, not an account of a drive failure I experienced.
The first clue is the label beside the number
I would start with three pieces of information: the capacity printed on the product, the exact wording in the storage utility, and the number of bytes if the utility provides it. A screenshot that says only “931” is not enough to diagnose anything.
“Capacity” and “available” answer different questions. Capacity describes the size of the selected device or volume. Available space describes what can still be used under that system's accounting rules. A folder's size is a third measurement. Comparing these numbers as if they described the same thing makes an ordinary difference look like lost data.
I would also check which object is selected. A physical disk may contain several partitions or volumes. The capacity of one selected volume need not represent the entire device. I do not need to alter those partitions to establish what the screen is measuring.
My first note would therefore be descriptive: “External device advertised as 1 TB; utility shows approximately 931 for the selected device; exact unit and byte count still to check.” That keeps an assumption from becoming a conclusion.
GB and GiB count the same bytes in different groups
The distinction is between powers of 1,000 and powers of 1,024. In the definitions used here, a megabyte contains one million bytes, while a mebibyte contains 1,048,576 bytes. A gigabyte contains one billion bytes, while a gibibyte contains 1,073,741,824 bytes. The NIST reference on binary prefixes documents these definitions and the symbols that distinguish them.
| Label | Meaning | Bytes represented |
|---|---|---|
| MB | Megabyte | 1,000,000 |
| MiB | Mebibyte | 1,048,576 |
| GB | Gigabyte | 1,000,000,000 |
| GiB | Gibibyte | 1,073,741,824 |
| TB | Terabyte | 1,000,000,000,000 |
A larger unit produces a smaller numerical count for the same quantity. Imagine describing the same distance in feet and yards: changing the unit does not shorten the road. Here, binary GiB are larger than decimal GB, so fewer GiB are needed to describe the same bytes.
I would not assume that every program labels its units consistently. The useful question is how the number was calculated. If the displayed label and the calculation disagree, a byte count or the software's documentation is more informative than the letters alone.
Reconstructing the 1 TB example with a calculator
For the advertised decimal capacity in our example, I divide the number of bytes by the number of bytes in one GiB:
**1,000,000,000,000 ÷ 1,073,741,824 ≈ 931.3225746 GiB.**
This is arithmetic on the advertised capacity. It is not a measurement taken from a real disk. It explains why a binary display can show approximately 931.32 for a quantity sold as 1 TB.
I can work through that division with the standard calculator offered in Convertix Online. I open the Web tool, choose Calculator, and use the two whole numbers above. There is no need to import the drive, upload a folder, or grant access to its files. The calculator is being used to interpret a measurement, not inspect hardware.
The result belongs in a sentence with its unit: “One decimal terabyte is approximately 931.32 gibibytes.” Writing just “931 GB” would reintroduce the ambiguity we are trying to remove.
For a quick comparison, the same method gives approximately 465.66 GiB for 500 decimal GB and 238.42 GiB for 256 decimal GB. These are calculated equivalents before any separate questions about formatting or occupied space. They are not promises about the amount available on a particular device.
Does that explain every missing gigabyte?
No. Unit conversion explains one possible difference, not every storage problem. A device can also have space associated with formatting, system requirements, existing files, or partitions. Those effects must be examined separately rather than folded into the GB/GiB explanation.
Apple's explanation of storage capacity distinguishes the decimal capacity used for product specifications from the smaller capacity available after formatting and system use. It also explains that the way capacity is reported can differ across software. That is why “all computers show 1 TB as 931” would be an unreliable rule.
In my fictional case, suppose the utility identifies the total physical capacity as approximately 931 GiB. That is compatible with the decimal label. If it then says only 700 GiB is free, the conversion does not explain the difference between 931 and 700. I am now asking about allocation and usage within the displayed capacity.
I would keep those two investigations separate. First, reconcile the unit. Then examine the selected volume's usage breakdown. I would not delete files simply to make a binary number look more like a decimal number; removing content cannot change how large a GiB is.
A small decision table prevents the wrong repair
These checks help me decide what to investigate next without treating a calculator as a disk diagnostic utility.
| What I can establish | What it suggests | My next step |
|---|---|---|
| About 1 trillion bytes, displayed near 931 GiB | Decimal/binary conversion is plausible | Compare like-for-like capacity labels |
| Total capacity is consistent, free space is much lower | The question concerns usage or allocation | Read the volume's usage information |
| I selected one partition rather than the device | The screen covers only part of the disk | Inspect the device/volume hierarchy |
| The byte count is far below the advertised capacity | Unit conversion alone is insufficient | Check the device identity and documentation |
| I cannot find the unit or definition | The evidence is incomplete | Consult the utility's help information |
The last two rows matter. A neat calculation should not persuade me to ignore a genuine discrepancy. If the underlying byte count is wrong, I need evidence about the hardware or configuration. Convertix can help with the numbers; it does not certify a drive's health, authenticity, or capacity.
The same distinction appears in attachment limits
Now I change the situation. A submission form accepts files up to “10 MB,” and my exported image is described elsewhere as “10 MiB.” Those labels are not interchangeable.
Ten MiB contains 10,485,760 bytes. A limit defined as ten decimal MB is 10,000,000 bytes. The file would exceed that byte limit by 485,760 bytes. This is a calculated example; the actual form might define its limit differently, so its documentation remains the deciding reference.
When a file is close to a limit, I would check its exact size rather than rely on a display rounded to one decimal place. “10.0 MB” can conceal a value just above the threshold. I would also distinguish a per-file limit from a limit for the whole request or message.
Changing the label from MiB to MB does not shrink the file. If the form needs fewer bytes, the file must actually change. For images, Convertix's public Web interface offers conversion, resizing, and target-size tools. I would work on a copy, choose an appropriate operation, then inspect the saved result and its actual size before submitting it.
A smaller file is not automatically a better one. A readable diagram or document photo still needs enough detail for its purpose. The goal is a compliant, usable copy—not simply the lowest possible number.
Pixels, bytes, and compression describe different things
A picture can have the same pixel dimensions as another picture while taking up a different amount of storage. Dimensions describe the image grid. File size describes the bytes used by the saved file. Its format and encoding also matter.
That distinction changes my approach to an upload problem. If a website asks for a particular width and height, I need to check dimensions. If it asks for a maximum number of bytes, I need to inspect file size. When it asks for both, satisfying only one condition is not enough.
I would write the requirements before making changes: accepted format, required dimensions, maximum file size, and any readability expectations. Then I would keep the original and create one clearly named submission copy. This avoids a folder full of nearly identical exports whose purpose I no longer remember.
The official Convertix product page separates the Web and iPhone experiences. This guide uses the browser calculator for arithmetic and refers only to the image tools publicly listed for the Web. It does not assume that every iPhone document feature is identical in the browser.
A lowercase b adds a different question
Storage uses bytes, but transfer rates are often expressed in bits per second. One byte contains eight bits. A rate labeled Mb/s is therefore not the same as MB/s. The NIST binary-prefix reference linked above also states the byte-to-bit relationship.
For an idealized calculation, a 100 Mb/s transfer rate corresponds to 12.5 MB/s when both prefixes are decimal: 100 divided by eight. That is an arithmetic relationship, not a prediction of a real download. Network overhead, the sending service, other traffic, and device performance can affect the observed result.
I would resist combining every conversion at once. First establish bits or bytes. Then establish decimal or binary prefixes. Finally check whether the number describes a quantity or a rate. This order makes a specification much easier to read.
It also prevents an unhelpful comparison between a file's size and an internet plan's headline speed. To estimate an idealized duration, the size and rate must first use compatible units. Real elapsed time needs separate measurement.
What I would keep from this investigation
For the drive, I would retain the advertised capacity, the selected device or volume, the exact byte count if available, and the utility's unit definition. For the upload, I would retain the destination's requirements and the size of the actual exported copy. They are different problems, even though both involve bytes.
I would describe the conclusion narrowly. “The 1 TB versus 931 GiB difference is consistent with decimal and binary units” is useful. “Nothing can be wrong with this drive” goes far beyond the calculation. Similarly, “This copy is below the stated byte limit” does not guarantee that a website accepts its format or contents.
If I need to explain the issue to someone else, one line of arithmetic and the original labels usually work better than a long argument about which software is right. The person receiving the explanation can repeat the division and see exactly which assumption was used.
Open Convertix Online to work through the calculation, or read the guide to Convertix's supported tools for a broader overview. The separate Convertix iPhone listing describes its current mobile capabilities and purchase terms. Product references were checked on September 14, 2026.