Understanding Data Storage Units: From Bits to Terabytes

Buy a "1TB" hard drive, plug it in, and your computer reports something like 931GB available. No files copied yet, and already 69GB is "missing." Stream a video at 1080p and your data plan drains faster than the file size on screen would suggest. Send a small image through an API and the payload is suddenly a third larger than the file on your disk. None of this is a bug, a scam, or a rounding error in your favor or against it. It is the result of two different counting systems, decimal and binary, being used interchangeably for decades, plus a handful of encoding rules that quietly inflate file sizes. Once you understand how storage units actually work, every one of these mysteries resolves into simple math.

Why a "1TB" Drive Never Shows 1TB of Space

Storage manufacturers and operating systems do not agree on what a terabyte is, and neither side is technically wrong. Hard drive manufacturers use the decimal definition: 1 kilobyte (KB) equals 1,000 bytes, 1 megabyte (MB) equals 1,000,000 bytes, 1 gigabyte (GB) equals 1,000,000,000 bytes, and 1 terabyte (TB) equals 1,000,000,000,000 bytes. This matches the metric system everyone learned in school, where "kilo" means a thousand and "tera" means a trillion.

Operating systems, on the other hand, often report storage using binary units, even while labeling them with decimal names. In binary counting, 1 kilobyte is 1,024 bytes (2 to the 10th power), 1 megabyte is 1,024 KB, 1 gigabyte is 1,024 MB, and 1 terabyte is 1,024 GB. Run the math: a drive advertised as 1,000,000,000,000 bytes, divided by 1,024 three times to convert to the binary "GB" your OS displays, comes out to roughly 931. That is exactly the gap you see. The drive is not missing anything. It is being measured twice, by two different rulers, and the difference grows as the numbers get bigger. At the terabyte scale, the decimal-versus-binary gap is about 9 percent, which is why it is so noticeable on larger drives.

Bits and Bytes: The Building Blocks

Before any of the larger units make sense, it helps to nail down the smallest ones. A bit is a single binary digit, either a 0 or a 1. It is the most basic unit of information a computer can store or transmit. On its own, a single bit can only represent two states, which is not very useful for representing letters, numbers, or colors.

A byte is a group of 8 bits. This grouping is not arbitrary; it became the standard because 8 bits can represent 256 distinct values (2 to the 8th power), which is enough to cover the full ASCII character set used for English letters, numbers, and punctuation, plus a generous range of control codes and extended characters. A single byte can represent any number from 0 to 255, which is also why pixel color values in images typically range from 0 to 255 per channel.

Everything above the byte is just a bigger grouping: a kilobyte is roughly a thousand bytes, enough for a short paragraph of plain text. A megabyte is roughly a million bytes, enough for a few seconds of MP3 audio or a small photo. A gigabyte is roughly a billion bytes, enough for a feature-length movie at moderate compression. A terabyte is roughly a trillion bytes, enough to hold hundreds of thousands of photos or thousands of hours of music.

KB vs KiB: Decimal and Binary Prefixes Explained

To resolve the ambiguity between decimal and binary counting, an international standards body introduced a separate set of binary prefixes in the late 1990s: kibibyte (KiB), mebibyte (MiB), gibibyte (GiB), and tebibyte (TiB). These always mean powers of 1,024. Meanwhile, KB, MB, GB, and TB were redefined (at least officially) to always mean powers of 1,000, matching the metric system.

In practice, almost nobody uses "kibibyte" in casual conversation, and most operating systems still label binary-counted values with decimal names like "GB" instead of the technically correct "GiB." This is exactly why the labels on a file properties window do not match the number on the box a hard drive came in. Both numbers are accurate. They are just answering slightly different questions: "how many bytes are there, counted in tens" versus "how many bytes are there, counted in twos."

If you regularly move between these systems, for example when budgeting cloud storage in GB but checking local disk usage in GiB, doing the conversion by hand is error-prone. A data storage converterhandles the decimal-to-binary conversion instantly across bits, bytes, kilobytes, kibibytes, megabytes, mebibytes, gigabytes, gibibytes, terabytes, and tebibytes, so you can plan storage purchases and cloud quotas without second-guessing which "GB" you are looking at.

Bandwidth vs Storage: Why Download Speed and File Size Feel Mismatched

Here is a second source of confusion that compounds the first: internet speeds are measured in bits per second, but file sizes are measured in bytes. An internet plan advertised as "100 Mbps" means 100 megabits per second, not 100 megabytes per second. Since a byte is 8 bits, 100 Mbps translates to a theoretical maximum of about 12.5 megabytes per second (100 divided by 8). In real-world conditions, overhead from network protocols, shared bandwidth, and Wi-Fi signal quality typically brings that down further, often to somewhere between 8 and 11 MB/s.

This is why downloading a 1 GB file on a "100 Mbps" connection takes well over a minute rather than ten seconds. The bits-to-bytes division is the single most common reason people feel like their internet speed does not match the number on their bill. The same logic applies to USB and storage transfer speeds, some of which are quoted in bits and others in bytes depending on the manufacturer and the marketing context.

When you are estimating how long a download or backup will take, the quick rule of thumb is: take your connection speed in Mbps, divide by 8, and that is roughly your maximum speed in megabytes per second. From there, dividing the file size in MB by that number gives you an estimated time in seconds.

Encoding Overhead: How Base64 Makes Files Bigger

Storage units get even more interesting once you start encoding binary data as text. Base64 is a method for representing binary data, like an image or a file attachment, using only 64 printable characters (A through Z, a through z, 0 through 9, plus two symbols). It exists because many systems, like email protocols, JSON payloads, and CSS files, were designed to handle text safely but can corrupt raw binary data in transit.

The catch is that Base64 encoding takes every 3 bytes of original binary data and represents them using 4 text characters. That is a 4-to-3 ratio, which works out to roughly a 33 percent increase in size. A 300 KB image becomes roughly a 400 KB Base64 string. This is why embedding images directly into HTML, CSS, or JSON (a technique sometimes used to avoid extra network requests for small icons) can backfire if the images are not tiny, since the encoded version is meaningfully larger than the original file.

If you want to see this overhead for yourself, a Base64 encoder lets you paste in text or upload a small file and instantly see the encoded output and its new size, which makes the 33 percent rule concrete rather than abstract.

Resolution, Megapixels, and File Size

Image and video file sizes are driven directly by resolution, which is itself a storage calculation. A digital image is a grid of pixels, and each pixel needs storage space for its color information. An uncompressed image's raw size in bytes is roughly: width in pixels, multiplied by height in pixels, multiplied by the number of bytes per pixel (commonly 3 for full RGB color, or 4 if there is also a transparency channel).

A 1920x1080 image (the standard "1080p" resolution) has about 2.07 million pixels. At 3 bytes per pixel for RGB color, that is roughly 6.2 MB uncompressed. A 4K image at 3840x2160 has about 8.3 million pixels, or roughly 24.9 MB uncompressed, four times larger, because doubling both width and height quadruples the total pixel count. This is why 4K video files and photos from modern phone cameras, which often shoot at 12 megapixels or more, take up so much more space than older, lower-resolution files.

Compression formats like JPEG, PNG, and WebP reduce these numbers dramatically by removing redundant or imperceptible information, but the underlying resolution still sets the ceiling. If you are not sure what resolution your own screen or device actually displays at, which matters when you are choosing how large to make images for a website or presentation, a screen resolution checker shows your current display's exact pixel dimensions so you can match assets to it rather than guessing.

Shrinking Files Without Losing Quality

Once you understand that file size is a direct function of resolution, bit depth, and encoding, it becomes clear why "compression" is not one single thing. There are two broad categories. Lossless compression, used by formats like PNG and ZIP, rearranges data more efficiently without discarding any information, so the file can be reconstructed exactly. Lossy compression, used by formats like JPEG and most video codecs, discards information that is unlikely to be noticeable, achieving much larger size reductions at the cost of some quality.

For most everyday images, photographs in particular, lossy compression at a moderate quality setting (around 70 to 85 percent) shrinks a file by 60 to 90 percent with a quality loss that is difficult to spot at normal viewing sizes. The math from the previous section explains why this matters so much: a 24.9 MB uncompressed 4K image can often become a 2 to 4 MB JPEG with no visible difference on a typical screen, simply because so much of the original pixel data was redundant or beyond what the human eye can distinguish.

Rather than calculating compression ratios by hand, an image compressor lets you drag in a file, adjust a quality slider, and see the resulting file size update in real time, so you can find the smallest size that still looks right for your use case.

Putting It All Together: Estimating Storage Needs

With these pieces in place, you can estimate storage needs for almost any scenario using simple multiplication. For photos, multiply the average compressed file size (often 2 to 8 MB for modern phone photos) by the number of photos you expect to take or store. A phone that takes 20 photos a day at 4 MB each uses about 80 MB per day, or roughly 29 GB per year, which is why phone storage fills up faster than people expect.

For video, the math involves an extra dimension: time. Video bitrate is typically measured in megabits per second, so a 1080p video recorded at 10 Mbps produces about 1.25 MB per second, or 75 MB per minute, or 4.5 GB per hour. Higher resolutions and frame rates increase this proportionally.

For backups and cloud storage, the practical approach is to total up your actual files (photos, documents, videos) using your operating system's built-in size reporting, remember that the displayed "GB" is likely binary (GiB) while the cloud provider's quota is likely decimal (GB), and add a buffer of 10 to 15 percent for that discrepancy plus future growth.

The recurring theme across all of this is that storage units are not mysterious once you separate the three things that get conflated: the counting system (decimal vs binary), the unit being measured (bits vs bytes), and the encoding or compression applied on top. Keep those three separate, and the next time a drive, a download, or a file size does not match your expectations, you will know exactly which one is responsible.