Shrinker Pro 1.2.0
Released 2026-09-13. Build 5. macOS 14+, Apple Silicon only.
The quality release, and the first one with a command line.
New install line
brew install jeso87/tap/shrinker
First release distributed through Homebrew as well as the DMG.
What shipped
Quality
Settings offers Super Low, Low, Standard, High for the lossy encoders, and the same control sits in the window footer so it can change between one drop and the next without opening a panel.
Standard is the default and produces exactly what earlier versions did — upgrading changes nothing about your output unless you choose it to. This was verified byte-for-byte against 1.1.0 across all 12 conversion routes before shipping.
Applies to JPEG, WebP, AVIF, HEIC. PNG and GIF are deliberately excluded — pngquant's --quality is a floor with an abort (it exits non-zero and writes nothing when it can't hit the minimum), and gifsicle's --lossy inverts the axis. Wiring either would convert a preference into a failure on hard images.
The shrinker CLI
Same compression engine, no window. Built for scripts, build steps, and AI assistants that can run a command but can't drag a file onto a drop zone.
shrinker photo.jpg # .min copy beside it
shrinker --quality super-low --to webp ./shots # a whole folder
shrinker --json --quality 85 diagram.jpg # one JSON line per fileTwo differences from the app worth remembering:
- It never reads saved preferences, so nothing converts unless
--toasks — except HEIC, which has no "keep" option anywhere and always becomes JPEG. --qualitytakes a plain number as well as a level name, for hitting a size target the four named stops don't reach.
Window footer
"Convert all to" moved from above the results list to a bar pinned along the bottom, now a dropdown, with Quality beside it. History scrolls above them. On a narrow window they stack rather than crowd.
"Off" became "App default" — says what actually happens (stored per-format rules apply) rather than only what doesn't.
Fixed: compressing a file can no longer make it bigger
Re-encoding an already-compressed image can produce a larger file, and the app used to write that result and report it as a saving. Now a same-format result larger than its source is discarded, original untouched, reported as 0%.
Was already happening: re-optimising a WebP produced a file ~36 bytes larger every time. Format conversion is deliberately exempt — a photo converted to lossless PNG is expected to grow, and that's what was asked for.