Compressing a video sounds like it should mean ruining it a little to make it smaller. Sometimes it does. Often it means removing work the original file was doing that nothing on your phone can see.
What is actually inside a video file
A video is not a stack of photographs. Storing it that way would be enormous. Instead, a codec saves occasional complete frames, called keyframes, and describes everything between them as changes from what came before: this block of pixels moved here, this region got slightly brighter, this corner did not change at all.
How much detail it spends on those descriptions is the bitrate, usually stated in megabits per second. Bitrate is the main lever on both file size and visual quality. A camera app picks a generous one because it is recording once and cannot know what you will do with the result.
Where the savings come from
Three places, in rough order of how much they usually matter:
- A newer codec. HEVC describes the same picture more efficiently than H.264. Older clips, and anything that came from a non-Apple source, are often still H.264 and re-encode well.
- A lower bitrate ceiling. Most handheld footage never needs the headroom the camera reserved for it.
- A resolution cap, if you want one. Capping at 1080p or 720p shrinks files considerably. It is also the most visible change, so it should be a choice rather than a default.
Savings vary a lot by source. Long 4K clips typically give up the most. A short video already encoded efficiently at low resolution may barely shrink at all, and an honest tool should tell you that rather than churn through it.
What lossy actually costs
Every re-encode discards some information permanently. Where you notice it, if you notice it:
- Smooth gradients such as skies and studio walls, which can develop faint banding.
- Low-light footage, where grain is expensive to encode and gets smoothed instead.
- Fast motion, where a tight bitrate has the least room to work.
There is also a generational point. Re-encoding an already-compressed file starts from a lossy source, so quality steps down rather than resets. Compressing the same clip repeatedly is a bad idea; compressing it once, well, usually is not.
What a compressed copy should never change
A smaller file that has lost its context is not a saving, it is damage. Unfill carries the following through to the new copy: creation date, location, the favorite flag, the original filename, and album membership. Color information, including HDR, is carried through the encode rather than flattened, and audio comes along with it.
That matters more than it sounds. Dates and locations are what Memories, the year view, and every search by place are built on. A cleanup that scrambled them would cost you more than the gigabytes were worth.
How Unfill approaches it
There are three named profiles, Keep quality, Balanced, and Smallest, and the individual knobs behind them if you want to set your own. Each profile is measured against your actual library rather than described in the abstract, so the estimate reflects your footage instead of a generic example.
Encoding runs on the device. Nothing is uploaded, and the optional assistant only ever sees aggregate counts and byte totals. It can suggest a screen or a filter; it cannot start an encode, commit one, or delete anything.
How to sanity check the result
Do not compress your whole library on the first run. Pick a handful of clips that represent your worst case, meaning low light, fast motion, and anything with a big smooth sky. Compress those, then compare before and after full screen, with sound, before you approve anything. Pending work sits there until you decide, so there is no rush.
If the samples look right to you, the profile is right for your library. If they do not, move up a quality step and try again. Unfill is coming to the App Store; support can help if a specific file behaves oddly.