TinyPNG4Mac: a native macOS client for the TinyPNG API

What TinyPNG4Mac actually does, and who it is for

The README describes TinyPNG4Mac as a third-party client of TinyPNG, the hosted image compression service. That framing matters: the app does not contain a compression algorithm. It takes image files, sends them to the TinyPNG API, and writes the compressed result back. Everything the service charges for or limits happens on TinyPNG's side, and the app is the desktop shell around it.

The audience is narrow and specific. You are on macOS, you compress images often enough that opening tinypng.com in a browser each time is friction, and you either already have a TinyPNG developer API key or are willing to register one. The README's usage list starts with exactly that step: register an API key at the TinyPNG developers page, then paste it into the Settings window. Designers exporting assets, documentation writers shrinking screenshots, and developers preparing web images all fit. Anyone who wants a general-purpose image tool with no account and no network call does not.

How the app moves images through the TinyPNG API

The repository is a Swift project with a single top-level source directory, TinyPNG4Mac/, plus a create_dmg.sh packaging script. There is no server component and no bundled command-line binary in the layout. Input arrives one of two ways: files or directories dragged onto the window, or a right-click on files and folders in Finder followed by Services, then Compress with Tiny Image. The README gives both paths.

The API key is stored through the Settings window, and the README notes you can edit it whenever you need to. From there the flow is: collect the image files, send them to TinyPNG, receive compressed bytes, write them out. Version 2.2.1 adds format conversion on top of that, either to a named format or by letting the app pick the smallest result among PNG, JPEG, AVIF and WEBP. That automatic pick is the interesting part, because it means the output extension is not necessarily the input extension, and a batch can come back mixed.

The same release note mentions a cache for the number of images compressed. Read that as a local counter, not an authoritative quota meter. The README does not say how the cache is invalidated or whether it survives a reinstall.

Installing TinyPNG4Mac and compressing your first folder

The README does not document a Homebrew cask or a build-from-source path. It points at the project's GitHub Release Page, so the install step is downloading a release artifact. The release list shows v2.2.1, v2.2.0 and v2.1.0, with the two 2.2.x builds published on 2025-12-03 and 2025-12-04.

After downloading, the README warns that macOS may refuse to open the app, and directs you to System Settings, then Security & privacy. That is the standard unsigned-or-unnotarized gatekeeper path, and the README treats it as expected rather than a bug.

Once it opens, register an API key at the TinyPNG developers page and paste it into the Settings window. There is no config file to edit and no environment variable involved; the key lives in the app's settings.

From there, drag a directory onto the window. The README's own sequence is:

# 1. Register an API key at https://tinypng.com/developers
# 2. Paste the key into the app's Settings window
# 3. Drag images or directories onto the window
# 4. Or right-click files/folders in Finder -> Services -> Compress with Tiny Image

What you should see is the compressed files written back, with the format-conversion behaviour from 2.2.1 applied if you enabled it. If nothing happens, the first thing to check is the API key, because every compression request depends on it.

The API key is the real dependency, and it is not optional

This is the limitation that decides whether TinyPNG4Mac is the right tool. The app has no offline mode. Without a valid TinyPNG API key, and without network access to TinyPNG, it cannot compress anything. The README's usage section assumes you have registered a key before you do anything else.

That has three practical consequences. First, TinyPNG's own free-tier quota applies to you, and the README does not restate what that quota is, so you have to check the TinyPNG developer page yourself. Second, image data leaves your machine for a third-party service, which rules the app out for confidential material under a policy that forbids external processing. Third, if TinyPNG changes or retires its API, this client stops working until it is updated. The README documents none of these constraints because they belong to the service, not the app, but they shape how you can use it.

The macOS version floor is the second constraint. The 2.2.1 release note states that version 2.0.0 and later support macOS 13 Ventura and above, and that lower versions should use a previous release. If you are on an older Mac, you are not on the current line.

TinyPNG4Mac compared with the web uploader and with local encoders

The obvious alternative is the TinyPNG website itself. Same backend, same API, same compression results. The difference is entirely in the interaction: the site requires a browser tab, manual file selection and manual download, while TinyPNG4Mac adds drag-and-drop, a Finder Services entry and a stored API key. If you compress a handful of images a month, the website is simpler and installs nothing. The app earns its place when the operation is frequent and you want it to feel like a macOS action rather than a web form.

A different alternative is a local encoder such as the command-line tools built around libpng, mozjpeg, or the AVIF and WEBP encoders. Those run offline, need no account, and fit into a build pipeline. They also require you to choose settings and wire up the invocation yourself, and their output quality and size will not match TinyPNG's, because the algorithms differ. The trade is hosted convenience with a quota against local control with configuration work. TinyPNG4Mac sits firmly on the hosted side, and it does not try to be scriptable: the README shows no CLI, no flags and no pipeline integration.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-04-13. The latest release is v2.2.1 from 2025-12-04, following v2.2.0 the day before and v2.1.0 in January 2025. So the project has a release cadence measured in months, with the most recent version at the time of writing being several months old and the last commit activity later than that release.

The licence is MIT, which is permissive: you can use, modify and redistribute the code provided the copyright notice and permission notice are preserved. That is a statement about the repository's licence text, not about TinyPNG's service terms, which are separate and govern your API key. Nothing in the README suggests the MIT grant covers the TinyPNG API itself.

Upgrade cost is low in the ordinary case, because the app is a downloaded artifact rather than a dependency you pin. The version floor is the one real upgrade trap: 2.0.0 dropped support for macOS below Ventura, so a user on an older system cannot simply take the newest release. There is no documented migration step and no data format to convert, since the only persisted state the README mentions is the API key and the compressed-image counter.

Editorial conclusion

Adopt TinyPNG4Mac if you already pay for or plan to use the TinyPNG API and want drag-and-drop plus a Finder Services entry instead of a browser tab. Skip it if you need offline compression, a command-line interface, or support for macOS versions below 13 Ventura, since version 2.0.0 and later require Ventura and the README points older systems at a previous release. Before relying on it, verify that your TinyPNG API key has enough monthly quota for your image volume, because the app reports a compressed-image count from a local cache and that counter is not a billing statement.

Frequently asked questions

Official sources

1. Issues
2. kyleduo/TinyPNG4Mac on GitHub
3. License: MIT
4. README
5. Releases