Why didn't my Mac get space back after I deleted files?

Three common reasons. The files are still in the Trash. They were APFS clones that share their space with another file. Or a Time Machine local snapshot still holds them. In the last case the space returns only when macOS removes the snapshot.

How do I see Time Machine local snapshots?

Run tmutil listlocalsnapshots / in Terminal. Each line is one snapshot, named with the date and time it was taken.

Is it safe to delete local snapshots?

macOS removes them on its own when space runs low. Deleting one by hand gives the space back sooner, but you lose that restore point. If your backup disk has not been connected for a while, a local snapshot may hold your one recent copy of a file.

Does Finder show the space I will get back?

No. Finder and du show a file's size. Neither shows how much of it is shared with a clone or held by a snapshot.

Deleted files on a Mac but got no space back? Here's why

On APFS, deleting a file and freeing its space are two different things. The Trash, clones and Time Machine's local snapshots each hold space. Here's how to check each one, with real measurements.

Updated 11 Oct 2026. Every figure here was measured on the developer's Mac, or on a test disk on it, and carries its date.

The short answer

A file's size is not the space you get back. On a Mac with APFS, three things can stand between deleting a file and seeing free space rise:

The Trash. Moving to the Trash frees nothing until the Trash is emptied.
Clones. A copy can share its blocks with the original. Deleting one copy frees nothing.
Local snapshots. Time Machine keeps snapshots on your startup disk. While one exists, the files it holds free nothing.

Check them in that order. The first takes seconds.

1. Empty the Trash

It sounds obvious, so check it first. On a test disk, moving two items to the Trash made free space go down by 16,384 bytes: the Trash's own folders. Emptying the Trash of one of them returned exactly what Spaceific had promised for it, 1,048,576 bytes (measured 8 Oct 2026).

Measure before and after, so you know what changed:

df -k /

The "Available" column is in kilobytes. Run it, empty the Trash, run it again.

2. Look for Time Machine local snapshots

Time Machine takes local snapshots on your startup disk, even when your backup disk is not connected. A snapshot keeps every file that existed when it was taken. Delete such a file and its space stays used until the snapshot goes.

tmutil listlocalsnapshots /

Each line looks like com.apple.TimeMachine.2026-10-11-024018.local: the date and time it was taken.

What this looks like, measured

A test file of 52,428,800 bytes, held by a snapshot, was deleted from the Trash. Free space changed by 4,096 bytes. Deleting the snapshot then freed 42,401,792 bytes (6 Oct 2026).
On 6 Oct 2026, a snapshot appeared at 19:58. While it existed, ~/.codex, ~/.cache and ~/.npm/_cacache would each have freed zero bytes. ~/.codex alone had read 757,518,336 bytes just before it. By 20:22 the snapshot was gone and the figures were back.
With no backup disk connected and little free space, Time Machine made 22 hourly snapshots over two days. macOS removed each one itself after 20 s to 43 min 38 s.
After a real backup to an external disk on 11 Oct 2026, its snapshot held every older file for 2 h 3 min to 2 h 4 min. During that time, a plan that would have freed gigabytes could promise only 38.7 MB: the files written after the backup began.

Not measured yet: how long snapshots last on a Mac with plenty of free space. They may last longer there.

Your options

Wait. macOS removes local snapshots on its own. On the developer's Mac it did so whenever free space was below Time Machine's target. This is the safe choice.

Delete one snapshot. Use the date from the list:

sudo tmutil deletelocalsnapshots 2026-10-11-024018

The risk: that restore point is gone. If your backup disk has been away for a while, a local snapshot may hold your one recent copy of a file you changed. Delete only snapshots you are sure you don't need.

3. Clones: copies that share space

When you duplicate a file in Finder, or copy it with cp -c, APFS makes a clone. Both files point at the same blocks until one is changed. So:

Delete one of two untouched clones, and nothing comes back.
Delete both, and the space comes back once.

Measured on a test disk (6 Oct 2026): each file of a clone pair could free 0 bytes on its own. Once one was deleted, the survivor freed its full 41,943,040 bytes.

Neither Finder nor du tells you a file is a clone. du counts every copy in full, which is why folder sizes can add up to more than your disk holds.

4. Hard links: one file, two names

A hard link is a second name for the same file. Delete one name and the file is still there under the other. On a test disk, removing one name of a 20,971,520-byte file freed 8,192 bytes.

The link count is the number after the permissions:

ls -l file-name

A count above 1 means another name still holds the file.

5. "Available" can include purgeable space

Finder's "Available" counts space macOS says it can free on its own, such as some caches. df shows only what is free right now. If the two disagree, that is why.

What to remember

Measure with df -k / before and after.
Empty the Trash.
Check tmutil listlocalsnapshots /, and usually wait.
Expect clones and hard links to free less than their size.

You deleted files. Why is there no space back?