Dinky: a macOS utility that converts files as it compresses them

What Dinky is, and the three file types it touches

Dinky is a small macOS utility that compresses images, videos and PDFs. The summary is drop files in, get smaller ones back.

The one-line description on the repository is blunter than the marketing copy: Dinky makes files smaller. The homepage is dinkyfiles.com, the language is Swift, and the licence is MIT.

The three file types are handled differently, and the differences matter more than the shared drop zone suggests.

For images, the app supports JPG, PNG, WebP, AVIF, HEIC/HEIF, TIFF and BMP as input, and outputs WebP, AVIF, lossless PNG or HEIC depending on your preference. There is an Auto mode that picks WebP or AVIF per image.

For video, the output is MP4 with either H.264 or HEVC, chosen through quality presets.

For PDFs, the default is to flatten the pages, which the README describes as reliable for smaller files on most scans and image-heavy documents, with an alternative that preserves text and links for a best-effort stream rewrite when size is secondary. Scan-like PDFs can optionally run Vision OCR on device first to lay down a text layer before the chosen pass, and born-digital PDFs skip OCR. Metadata is stripped where applicable, images respect max dimension and file size targets, and output is saved next to the original by default.

So the PDF path is a genuine two stage design rather than one setting, and the OCR step is the reason a scanned document can end up both smaller and searchable.

System requirements: Apple Silicon and macOS 15, with no Intel fallback

The requirements are short and they exclude a large part of the Mac market, so read them before anything else.

Dinky requires an Apple Silicon, meaning an M-series Mac, and macOS 15 (Sequoia) or later. The README adds a practical warning: current 2.x DMG and Homebrew cask builds are not for Intel-based Macs, and Finder may show the app icon with a slash through it on the wrong architecture.

That warning tells you something about how the project is built. The repository layout shows an Xcode project (`Dinky.xcodeproj`), a `Dinky/` directory for the app, a `DinkyCoreImage/` directory, a `DinkyTests/` directory, an `AppIcon.icon/` directory and a `release.sh` script for packaging. The CoreImage directory is the substantive part, because Core Image is Apple's image processing framework and it is the native path for the image work rather than a cross platform command line tool wrapped in a window.

The macOS 15 floor is also consistent with a native SwiftUI application that uses current system frameworks. The README also mentions that Dinky follows the system's own conventions elsewhere, and lists a launch at login option, a clipboard hotkey that works system wide, and a one click update that checks for a new release, installs it and relaunches without a browser or a re-drag.

The size claim in the feature list is 35 MB installed, which is a fair benchmark against the competition the README names, and it is the kind of number that comes from the packaging choices rather than from the compression engine.

Installing through Homebrew, and the 1.x versus 2.x split

Installation is a tap and a cask install.

brew tap heyderekj/dinky https://github.com/heyderekj/dinky
brew install --cask dinky

The README explains why the cask lives in the repository itself, pointing to `Casks/README.md` for that reasoning, which is the kind of detail that usually signals a deliberate decision rather than an accident.

The release history matters here, because the feature set changed with the major version. 1.x, from 1.0 on, was images only. 2.0 added videos and PDFs alongside images. Older 1.x DMGs and ZIPs stay on GitHub Releases for anyone who needs them, but the guidance is to use the latest release for full format support.

That matters for a specific reason beyond curiosity. A 1.x build on an old Mac might be exactly what you want if you only compress images, and the 1.x artefacts are still there. But if you need video or PDF, the 2.x line is the only option, and the 2.x line is the one with the Apple Silicon and macOS 15 requirement. So the choice is not old build less capable versus new build more capable, it is old build images only versus new build everything but a modern Mac.

The recent release cadence is fast. The last three tags are Dinky 2.15.0, Dinky 2.14.0 and Dinky 2.13.2, and the first two landed on the same day, 2026-09-25. The last push to the tree was on 2026-10-18. This is a project shipping frequently, which for a desktop utility is normal and for a tool you might script against is worth noting.

The compression pipeline: conversion, quality search, and PNG lossless

The interesting engineering in Dinky is not the file drop, it is the choice of how to make a file smaller.

The README is blunt about where the savings come from, and it is a differentiator rather than a boast. ImageOptim squeezes your JPEG and hands it back as a JPEG. Dinky converts to WebP, AVIF, lossless PNG or HEIC, which is where 30 to 80 percent of the real savings live. The README also notes that Optimage does this too, but costs money and weighs 62 MB.

So the default behaviour is transcoding, not recompression, and the format choice is the primary lever. A JPEG recompressed at a lower quality is still a JPEG that every browser must decode; a WebP or an AVIF is a different codec with a different decoder and a smaller result for the same perceptual quality.

Within a format, Dinky then works on quality. Smart quality auto-detects photo versus graphic, where a graphic means a UI, illustration, logo or screenshot, per image and picks the quality accordingly, and you can force Photo, Graphic or Mixed per preset. Max width resizes on the way out with common web presets or a custom value. Max file size is the more interesting one, because it binary-searches the quality level to hit an exact MB target. A binary search over quality settings is the right shape for that problem, since the size to quality relationship is monotonic enough to search but too irregular to solve analytically.

PNG is the exception, and the README names the tool. PNG lossless runs oxipng on PNGs when you need to keep transparency or format fidelity. That is a different operation from lossy compression: oxipng re-encodes the PNG losslessly, so the pixels are identical and only the encoding improves.

For video, the output is MP4 with H.264 or HEVC and quality presets, so the same transcoding logic applies, with the codec as the choice. For PDFs, the two passes are flattening, which rasterises the page and is reliably small for scans, and preserving text and links with qpdf and PDFKit for a best-effort stream rewrite.

Batch behaviour: watch folders, job caps, file order and skip thresholds

The batch features are where a personal utility becomes a pipeline, and they are described in more detail than the compression features.

The watch folder points Dinky at a directory and new supported files are compressed automatically, either globally or per preset with its own folder. That is the set-and-forget mode, and the launch at login option exists to support it.

Parallel work is capped rather than unbounded. Batch speed offers one at a time (Fast), up to three (Faster), or up to eight (Fastest). The cap exists because the compression work is CPU bound and running every file at once on a machine that is also doing something else is how a tool gets uninstalled.

Batch order is optional and the default is deliberately the opposite of what a throughput optimiser would choose. The option starts with the largest files first to finish the full batch sooner, but the default is smallest first for quicker early feedback. That is a product decision about perceived responsiveness rather than total runtime, and it is a good example of a small utility optimising for the person watching rather than for the clock.

The skip threshold is a related safety valve. Files below a minimum savings target are skipped, with the options Off, 2 percent, 5 percent or 10 percent. On a folder of mixed assets, that stops Dinky from rewriting files it cannot meaningfully improve, which matters because a rewrite of an already-optimised file still costs you the original's metadata and your time.

Originals handling is the other consequential setting. On every successful compress you can keep the original, move it to Trash, or move it to a Backup folder of your choosing, and watch folders can use their own setting. The Trash option is the one to think about, because it is destructive and it is the default a person would reach for.

Batch compression runs multiple files concurrently with live results as they finish, and the results list is designed to be actionable rather than a completion screen, with a Show in Finder action to jump to any compressed file.

Scripting surfaces: presets, Apple Shortcuts, a CLI and a local serve endpoint

There are four ways to drive Dinky that do not involve dragging a file, and they differ in how much they cost you to set up.

Compression presets are the least technical. A preset saves a named configuration with format, quality, limits, destination, watch folder and filename settings, and applies in one click. Most of the settings in the feature list belong to a preset, which is the right place for them, because the alternative is re-choosing a format and a quality for every file.

Apple Shortcuts is the second. A native Shortcuts action compresses images from automations, and custom keyboard shortcuts can rebind Open Files, Clipboard Compress, Compress Now, Clear and Delete in Settings, Shortcuts. The clipboard path is worth a note, because ⌘⇧V pastes a copied image straight into Dinky and the hotkey works system wide, even when Dinky is not focused.

The CLI and the local API are the third, and they are described as optional and for pro users. The `dinky` CLI and a local `dinky serve` endpoint exist for scripts and AI-agent workflows, with `--json` output, and the `serve` endpoint stays on the Mac and needs a token.

That last clause is the security boundary and it is stated clearly. The serve endpoint is a local endpoint on the machine, protected by a token, not a network service, and the wording is deliberate enough that it should not be read as anything else.

URL compression is the fourth input path. You can drop or paste a direct `http(s)` link to an image, video or PDF, and Dinky downloads it, with a maximum of 500 MB, into a temp folder, compresses it and cleans up after itself. The size cap and the temp folder cleanup are the two details that matter, since a download of arbitrary size into a temporary directory is the kind of feature that needs both limits stated.

Where Dinky does not fit

The platform constraint is the loudest one. Apple Silicon only, and macOS 15 or later, with no Intel build in the 2.x line. A designer on an older Intel Mac, or anyone on Windows or Linux, is out, and the README is honest enough to warn that Finder will show the app with a slash through it rather than failing gracefully.

The second limitation is the one implied by the pro user framing of the CLI and the serve endpoint. Dinky is a desktop utility first, and the automation surfaces exist but are described as optional, they are local, and the serve endpoint needs a token. If your requirement is to compress images on a build server or in a CI job, the design does not point there.

The third is a consequence of the format choices, and it is worth thinking about before you convert everything. If you convert a JPEG to AVIF, you have changed the format, and anything downstream that expects a JPEG will need to handle AVIF. The README is direct that most of the savings live in the conversion rather than in the recompression, which is true, and it also means the choice is a real trade rather than a free win. The before and after preview, side by side or as a slider, is there precisely so you can make that judgement per image.

The fourth is about the lossless PNG path. Running oxipng on PNGs helps when you need to keep transparency or format fidelity, and that is a different goal from making a file small. A PNG that is a logo stays a PNG and gets re-encoded, and a PNG that is a screenshot may be better served by converting it to WebP if nothing needs the alpha channel.

The alternative approach, and there is a real one, is to run the encoders yourself in a build script. A Node or Python pipeline that calls the AVIF and WebP encoders directly gives you reproducible output, checks the result into the repository, and runs on any machine. The difference in approach is direct. Dinky's route is interactive and per-machine, with a UI, watch folders and a compression log, and it is the right answer when a person is the unit of work. A build script is the right answer when a deploy is the unit of work.

Editorial conclusion

Adopt Dinky if you work on an Apple Silicon Mac and compress images for the web regularly enough that doing it by hand has become a chore, and if converting to a modern format rather than only shrinking a JPEG is part of what you want. Do not adopt it if you need Intel Mac support, if you need to run it on Windows or Linux, or if you are automating compression at scale on a server, because the CLI and local API are described as optional features for pro users and the `serve` endpoint stays on the Mac. Before your first batch, check the current release notes for the format support you need, since the 1.x line was images only and 2.0 is what added video and PDF.

Frequently asked questions

Official sources

1. heyderekj/dinky on GitHub
2. License: MIT
3. Project website
4. README
5. Releases