macOS 14+ · Universal binary · Your files never leave the Mac
A native macOS app collecting the utilities you keep needing — unlock a PDF, get HEIC out of your camera roll, squeeze a folder of screenshots, resize a batch for the web. Drop files in, get files out. Your files are never uploaded anywhere.
Latest release · Apple silicon & Intel
Free and MIT licensed · one extra step on first launch
The toolbox
Every tool accepts multiple files at once — drag-and-drop or a file picker — processes them in parallel, and reports a result per file. One bad file never stops the batch.
Saves a decrypted copy of a PDF you already know the password for. Text stays selectable and searchable.
file-unlocked.pdf beside the originalHEIC ⇄ PNG ⇄ JPEG ⇄ TIFF, plus WebP where macOS can encode it. Reads RAW too.
Lossless and format-preserving, or lossy with a quality slider when you want the bytes back.
Fit inside a box, clamp the longest side, scale by percentage, or force exact pixels.
Behaviour you can rely on
Most of the work in a file utility is what happens on the unhappy path. These are the guarantees the app is built around.
All processing happens on-device — your PDFs and photos stay on the disk they were already on. The file-processing core has no networking in it at all; the only thing that talks to the network is the update check, and it asks first.
Results are written next to the input, or into a folder you pick, with a suffix like -unlocked, -compressed, -resized.
A name collision becomes photo-1.png, photo-2.png, and so on. You can run the same batch twice without losing the first result.
Re-encoding a photo can honestly produce more bytes — HEIC is roughly twice as efficient as JPEG. When that happens the original bytes are copied instead.
EXIF orientation is baked into the pixels on resize, so iPhone photos come out upright instead of sideways in whatever you paste them into.
Updates are checked against an Ed25519 key baked into the app before anything installs, so the download host doesn't have to be trusted. Publishing one needs a private key that isn't on GitHub.
Install
Grab Toolbox-<version>.dmg from the latest release.
Open the disk image and drop Toolbox onto the Applications shortcut inside it.
Right-click Toolbox in Applications → Open → Open. Once per machine.
After that it keeps itself current: on first launch it asks whether to check for updates automatically, and you can change your mind later in Settings.
This build isn't notarized by Apple, so Gatekeeper won't let a plain double-click through on first launch. Right-click → Open is the standard way to approve it, and it's only needed once — after that it opens normally.
Notarization needs a paid Apple Developer account. The scripts in the repo support
it (Scripts/notarize.sh), and the app stays free either way —
notarization buys Gatekeeper trust, not a licence.
One honest trade-off in that default build: Library Validation only loads libraries whose Team ID matches the executable's, and an ad-hoc signature has no Team ID — so macOS would refuse to load the bundled updater framework. Ad-hoc builds therefore turn that check off, which also lets other unsigned libraries be injected into the process. Developer ID builds keep it on, because their Team IDs match.
| Signing mode | Command | What other people see |
|---|---|---|
| Ad-hoc default | ./Scripts/build-app.sh |
Works, needs right-click → Open once |
| Developer ID | ./Scripts/build-app.sh --sign auto |
Fewer warnings, still not fully trusted |
| Notarized | --sign auto then ./Scripts/notarize.sh |
Normal double-click, no warnings |
For developers
Requires Xcode 16 or newer. One dependency — Sparkle, for updates — which SwiftPM fetches for you; the ToolboxKit processing core has none at all.
// clone
git clone https://github.com/lazzyms/toolbox.git
cd toolbox
// run the test suite
swift test
// → dist/Toolbox.app (universal)
./Scripts/build-app.sh --version 1.0.0
// → dist/Toolbox-1.0.0.dmg
./Scripts/make-dmg.sh --version 1.0.0
// build, sign the feed, tag, release
./Scripts/release.sh --version 1.1.0Sources/ToolboxKit/ processing, no UI
PDF/ PDFUnlocker
Images/ ImageProcessor, ResizeSpec
Support/ BatchRunner, OutputNaming
Sources/Toolbox/ SwiftUI app
Utility.swift the tool registry
Components/ DropZone, FileList, ToolScaffold
Features/ one view per tool
Updates/ Sparkle wiring, Settings
Resources/ Info.plist, entitlements, icon
Scripts/ build-app, make-dmg, release
docs/ this site + appcast.xml
Tests/ 37 tests
Sources/Toolbox/Utility.swift is the only place that knows the tool
list, and BatchRunner.run already handles concurrency, progress and
per-file error isolation — a new tool usually needs no threading code of its own.
ToolboxKit as a plain file-in / file-out function, so it's unit-testable without a running app.Features/, wrapped in ToolScaffold — you get drag-and-drop, batching, progress and Finder reveal for free.Utility entry to Utility.all and add its id to the switch in makeView().Questions
No. It decrypts using the password you supply — it doesn't crack, guess or brute-force anything. If you don't know the password, this app can't help you.
Your files, never. Every PDF and image is read and written on your own disk, and the ToolboxKit code that does that work has no networking in it at all — there's no account, no telemetry and no analytics. The one thing that does reach the network is the update check below, which asks before its first request and can be switched off.
Through Sparkle, against a feed hosted on this site. On first launch the app asks whether to check automatically — nothing is requested before you answer. Say yes and it checks once a day; either way Toolbox → Check for Updates… works whenever you want it, and both behaviours are togglable in Settings.
Every download is verified against an Ed25519 public key baked into the app bundle before anything is installed, and the matching private key lives only in the maintainer's Keychain — so a compromised GitHub account on its own can't push code to installed copies.
Under App Sandbox, picking photo.heic doesn't grant permission to create photo.png beside it — which would break the default “save next to the original” workflow. It runs under the Hardened Runtime instead, which keeps the code-integrity protections without restricting where results can be written. See Resources/Toolbox.entitlements.
Probably not. Some images genuinely can't be re-encoded smaller — an already-efficient HEIC, or a photo pushed into PNG. Rather than hand you a larger file, the app copies the original bytes through and keeps the right extension.
That file fails and the rest continue. The results list tells you which one it was and why, so you can retry just that file.
macOS 14 Sonoma and later, on both Apple silicon and Intel. WebP encoding is only offered when the running system can actually write it — the option hides itself rather than failing at save time.
Open an issue on GitHub. Small, local, file-in/file-out jobs are exactly what this is for. If you'd rather build it, CONTRIBUTING.md walks through the three edits a new tool needs.
Yes — all of that. Toolbox is under the MIT licence, so you can use it, modify it, ship it under your own name and charge money for it, commercially or otherwise. The only condition is that you keep the copyright and licence notice somewhere in your copy. No permission needed, and nothing to pay.
Two practical notes if you do: the app ships your own build, so you'll want to point SUFeedURL and the Ed25519 key in Resources/Info.plist at your own update feed rather than this one, and Sparkle — the only dependency — is MIT licensed too, so it comes along on the same terms.