Jul 28, 2026 · 3 min read

Compress or Delete: Which Actually Frees More Space

Deleting frees more per file, compressing frees more across a library. Here is how to choose, and why compression pays out later.

Both free space. They do not free it the same way, and they do not cost you the same thing. Here is how to decide without turning a cleanup into a whole afternoon.

The short answer

Deleting frees more per item, because it frees everything. Compressing usually frees more across a whole library, because you will actually agree to do it to hundreds of files you would never agree to delete. The file you refuse to delete is exactly the file worth compressing.

What deleting gives you

All of the bytes, and none of the file. It is the right call for blurred shots, accidental recordings, expired screenshots, screen recordings you made once to send to someone, and four of the five near-identical frames of the same moment.

The cost is that it becomes final once Recently Deleted expires. That 30-day window is a safety net, and it is also why deleting never feels instant.

What compressing gives you

A smaller copy of the same footage. The biggest wins typically come from long video shot at high resolution and high bitrate, and from older clips recorded in H.264 that re-encode to HEVC efficiently. A short clip already encoded well at low resolution has little left to give.

The costs are quality you cannot recover once the original is gone, and time. Encoding is real work. A large backlog can run for hours, and the phone would rather be on power while it happens.

Compression frees nothing until you commit

This is the part most storage apps skip. Compressing writes a new copy. Until you approve the result, the original and the copy both sit on disk, so your free space briefly goes down rather than up.

In Unfill, approving has one name in every place it appears: Keep compressed. It removes the originals for the items you approved, and iOS then holds those originals in Recently Deleted for 30 days. So the honest sequence is compress, review, keep compressed, empty Recently Deleted. The space arrives at the end, not at the start.

Rule of thumb. If you would not miss it, delete it. If you would miss it but will never need it at full quality, compress it. If it is irreplaceable and you may print or re-edit it, leave it alone.

Decide by regret, not by bytes

Sorting by size tells you where the weight is, not what to do about it. Three questions settle most files faster than any number:

  • Would I be upset if this were gone in a year?
  • Will I ever view this larger than a phone screen?
  • Is there already a better version of this same moment in my library?

A yes to the third question usually means the answer is delete, not compress. Read more on finding duplicate photos if that describes most of your library.

Doing both in one pass

The two actions have to stay separate or you end up compressing something you already decided to bin. Unfill treats them as mutually exclusive: anything marked for deletion is excluded from compression candidates, and anything with a pending compressed copy stays out of the finders until you decide its fate. Change your mind about a deletion and the file becomes compressible again.

Everything is analyzed on the device, and nothing runs on its own. The optional assistant sees aggregate counts and byte totals only, and can suggest which screen to open next. It cannot delete, compress, commit, or start work on your behalf. Unfill is coming to the App Store; support can answer anything this did not.