Your 1 TB Mac has 926 GiB. Here is exactly where the rest went.

The SSD in this MacBook Pro is sold as 1 TB. df -h says 926 GiB. That gap is usually explained as decimal versus binary units and left there, which is incomplete: the unit convention accounts for most of it, but 5.49 GiB of the difference is real space that the APFS container consumes and never gives back. Here are the byte counts for both.

5.89 GB

Three tools, three answers

Ask macOS how big the disk is and the answer depends entirely on which tool you ask.

diskutil info disk0 | grep "Disk Size"
diskutil info /System/Volumes/Data | grep "Container Total"
df -h /System/Volumes/Data | tail -1
df -H /System/Volumes/Data | tail -1

On this machine:

Tool	Reports	In bytes
diskutil info disk0	1.0 TB	1,000,555,581,440
diskutil container total	994.7 GB	994,662,584,320
df -h	926 Gi	994,662,584,320
df -H	995 G	994,662,584,320

Notice that the last three rows are the same number of bytes rendered three ways. df -h divides by 1024 three times and calls the result Gi. df -H divides by 1000 three times and calls it G. diskutil does the same as df -H but writes GB. None of them is wrong, and the only genuinely different figure in the table is the first one.

The part that is only arithmetic

A gibibyte is 1,073,741,824 bytes. A gigabyte, as storage manufacturers and macOS both use the word, is 1,000,000,000 bytes. The ratio between them is about 7.4 percent, and that is the entire origin of the 926-versus-995 discrepancy.

Convert the advertised capacity and the difference disappears:

1,000,000,000,000 bytes  /  1,073,741,824  =  931.32 GiB

So a drive honestly sold as 1 TB was always going to show as roughly 931 GiB in any tool that counts in binary units. That is 68.7 GiB of apparent loss before the filesystem has done anything at all, and it is not loss in any physical sense. The bytes are there. They are being counted in a different base.

This is where most explanations stop. On this machine it leaves 4.97 GiB unaccounted for.

The part that is actually gone

The raw device is not 1,000,000,000,000 bytes. It reports slightly more:

Disk Size: 1.0 TB (1000555581440 Bytes)

That is 1.00056 decimal terabytes, or 931.84 GiB. Apple shipped marginally more than the label promises, which is worth noting given how often the assumption runs the other way.

The APFS container laid on top of that device reports:

Container Total Space: 994.7 GB (994662584320 Bytes)

Subtract:

1,000,555,581,440  -  994,662,584,320  =  5,892,997,120 bytes
                                       =  5.89 GB
                                       =  5.49 GiB

931.84 GiB

That 5.49 GiB is not a unit artefact. It is capacity the device has that the container does not expose. It goes to APFS structures: the container superblock and its checkpoints, the space manager’s allocation bitmaps, the object map, the reaper, and the reserve APFS holds so that copy-on-write operations cannot fail for want of somewhere to write. A copy-on-write filesystem that ran completely out of free blocks could not even delete a file, because deleting is itself a write. Holding some capacity back is what prevents that state.

Putting the whole gap together

Starting from the number on the box and ending at the number in df -h:

Step	GiB	What happened
Advertised 1 TB	931.32	Decimal to binary conversion only
Actual device	931.84	The drive is fractionally larger than advertised
APFS container	926.35	5.49 GiB consumed by container structures

The headline gap of about 74 GiB between “1 TB” and “926 GiB” is therefore 68.7 GiB of arithmetic and 5.49 GiB of filesystem. Only the second number represents storage you cannot use, and it is roughly 0.55 percent of the drive rather than the 7 percent the raw comparison implies.

Why you should measure this rather than look it up

Container overhead is not a fixed percentage and it is not a constant you can quote from another machine. It depends on container size, on how many volumes are inside it, on snapshot state, and on how the space manager has laid out its metadata over the life of the disk. A figure measured on a 1 TB drive tells you very little about a 512 GB or 4 TB one.

The measurement takes one command and a subtraction:

# Raw device, in bytes
diskutil info disk0 | grep "Disk Size"

# What the container exposes, in bytes
diskutil info /System/Volumes/Data | grep "Container Total"

Subtract the second from the first. Whatever you get is what APFS is holding on your machine, today.

One number this does not explain

If your disk is showing far less free space than the files on it account for, container overhead is not the culprit at this scale; 5.49 GiB is too small to be the thing you noticed. Local Time Machine snapshots are the usual answer, and they are reported as purgeable rather than used, which is why the arithmetic in Finder can look impossible. That is a different measurement and a different article.

What container overhead does explain is the last few gibibytes of the gap between the label on the box and the number in your terminal, once the unit conversion has been done honestly.

Doing the same arithmetic on your machine

The two commands and one subtraction, as a single function:

apfsoverhead() {
  local raw container
  raw=$(diskutil info disk0 | awk -F'[()]' '/Disk Size/ {print $2}' | tr -dc '0-9')
  container=$(diskutil info /System/Volumes/Data | awk -F'[()]' '/Container Total/ {print $2}' | tr -dc '0-9')
  awk -v r="$raw" -v c="$container" 'BEGIN {
    printf "raw device      %15.0f bytes  %8.2f GiB\n", r, r/1073741824
    printf "apfs container  %15.0f bytes  %8.2f GiB\n", c, c/1073741824
    printf "overhead        %15.0f bytes  %8.2f GiB  (%.2f%%)\n", r-c, (r-c)/1073741824, (r-c)/r*100
  }'
}

On this machine that prints an overhead of 5.49 GiB, or 0.59 percent of the device. Your figure will differ, because container overhead scales with container size, with the number of volumes inside it, and with how the space manager has laid out metadata over the life of the disk.

That variability is the reason to measure rather than to look up a number someone else published.

The volumes inside the container

One more layer is worth seeing, because it explains why several volumes can each report the same free space:

diskutil list disk3

An APFS container holds multiple volumes, and they share a single pool of free blocks rather than each having a fixed allocation. On a modern Mac that is typically the read-only system volume, the Data volume holding everything you own, plus Preboot, Recovery and VM.

Because they share the pool, df reports the same available figure for all of them. That is not a bug and it is why adding the per-volume used figures together and comparing against the total produces a number that makes no sense: the system volume’s 12 GiB and the Data volume’s 432 GiB are drawn from one 926 GiB pool, and the free figure is the pool’s, not each volume’s.

What this does not explain

The overhead measured here is roughly half a percent. If your disk is showing tens of gigabytes unaccounted for, container overhead is far too small to be the cause and you are looking at a different mechanism.

Local Time Machine snapshots are the usual answer, and they are reported as purgeable rather than used, which makes Finder’s arithmetic look impossible:

tmutil listlocalsnapshots /

Cloned files produce the opposite discrepancy, where du reports more than is actually consumed because shared blocks are counted once per file. When those two tools disagree, df is the one describing what you can still write.