Gifski on macOS: a GUI wrapper around the gifski encoder, and its limits

What Gifski solves, and for whom

The GIF format is a poor container for video. It has a limited palette, no real inter-frame compression, and file sizes that grow fast with length and resolution. Most converters accept that and produce banded, dithered output. Gifski's pitch is different: it uses pngquant's cross-frame palettes and temporal dithering so each frame can draw on thousands of colors, with a frame rate ceiling of 50 FPS. The README frames the target use case directly, animated GIFs for showing off design work on Dribbble, which tells you the intended clip length is short and the intended audience is people who care how the result looks.

The app is for macOS users who have a video file and want a GIF without assembling a command line. It is not a library, not a service, and not a cross-platform tool. The README answers the Windows and Linux question with a flat no, and points to a separate cross-platform command-line tool. If your workflow is a build step or a server job, the GUI is the wrong layer.

The pipeline: pngquant palettes, gifsicle for size

Gifski is a front end. The README states it is a macOS app for the gifski encoder, which itself converts video to GIF animations using pngquant's features for cross-frame palettes and temporal dithering. A second encoder, gifsicle, is used when you want smaller, lower-quality output. That is what the Quality slider maps to.

The data flow is therefore: video file in, frames extracted, palette built across frames rather than per frame, GIF encoded, then optionally re-encoded by gifsicle for size. The repository layout reflects this. There is a Gifski/ directory for the Swift app, a Share Extension/ directory, a Tests/ directory, and a gifski-api/ directory, which is where the encoder binding lives. The primary language is Swift, and the build instructions require Rust, because the encoder is not written in Swift.

Input support is inherited from macOS, not implemented by the project. The README says Gifski supports all the video formats macOS supports, listing .mp4 and .mov with H264, HEVC, ProRes and similar. The QuickTime Animation format is the documented exception, and the README recommends ProRes 4444 XQ instead, noting it also carries an alpha channel. That is a real constraint: if your source is QuickTime Animation, you must transcode before Gifski will help.

Installing Gifski and converting your first mp4 to GIF

There is no package manager install for the app. The README's Download section links to the Mac App Store, and the requirement is macOS 26 or later. Older builds are listed as direct zip downloads for macOS 13, 12, 11, 10.15, 10.14 and 10.13, and a non-App Store version is offered for users who cannot reach the App Store. That last one will not receive automatic updates; the README says it is updated once a year.

Once installed, the shortest path is to open a video with the app. The README documents a share extension and a system service, so you can also send a file from the Share menu or the Services menu of another macOS app. For a screen recording, the README's tip is to click the thumbnail that appears when recording finishes and choose Share.

If you would rather not open the app at all, the README documents a Quick Action shortcut that converts from Finder. It requires the TestFlight version of Gifski, and the README links a downloadable shortcut. Multiple shortcuts can be created with different settings such as quality, dimensions or looping.

The editor exposes settings for dimensions, speed, frame rate, quality, cropping and looping. Two keyboard behaviours are documented: after converting, Command+C copies the GIF and Command+S saves it; in the width and height fields, the arrow keys change the value by 1 and holding Option changes it by 10.

If your source is a sequence of PNG images rather than a video, the README gives this command, which builds a ProRes file with FFmpeg and hands it to Gifski:

TMPFILE="$(mktemp /tmp/XXXXXXXXXXX).mov"; \
	ffmpeg -f image2 -framerate 30 -i image_%06d.png -c:v prores_ks -profile:v 5 "$TMPFILE" \
	&& open -a Gifski "$TMPFILE"

The README notes the images must be named in the format image_000001.png and that the -framerate value should be adjusted to match. It also requires FFmpeg, installed for example with `brew install ffmpeg`.

Building from source is a separate route. The README lists three prerequisites before opening the project in Xcode:

curl https://sh.rustup.rs -sSf | sh
brew install SwiftLint
xcode-select --install

Rust is needed because the encoder is a Rust component. SwiftLint is the lint step, and xcode-select installs the command line tools.

Where Gifski stops: WebM, batch work, and the frame rate ceiling

The clearest limitation is format support. The README states Gifski supports the video formats macOS supports, and that this does not include WebM. It suggests converting to MP4 first with another app. If your capture tool emits WebM, Gifski is not the tool until you transcode.

The second limitation is concurrency. Running multiple conversions at the same time is, in the README's words, not supported in the app itself. The documented workarounds are the Shortcuts action, or opening multiple instances with `open -na Gifski`. The README attaches a warning to that second option: do not have the editor view open in multiple instances, because changing a setting such as quality will change it in all of them. That is a shared-state bug in disguise, and it is worth reading before you build a parallel workflow on it.

The third is the frame rate ceiling. Gifski supports up to 50 FPS, and the README explains why 60 FPS and higher are not offered: browsers throttle frame rates above 50 FPS and play them at 10 FPS. This is a correct decision, but it means a 60 FPS source will be resampled rather than preserved.

Finally, size. The README's own FAQ opens with the complaint that generated GIFs are huge, and the advice is to reduce dimensions, FPS or quality. The bounce (yo-yo) option doubles the frame count, and the README states the file size will double as well. Nothing here compresses a long clip into something small; the format does not allow it.

Gifski versus the command-line gifski and FFmpeg

The most direct alternative is the cross-platform command-line tool the README itself names when asked about Windows and Linux. It is a different product with the same encoder underneath. The difference in approach is the interface layer: the app gives you a GUI, a share extension, a system service, a Quick Action shortcut and a quality slider that switches to gifsicle; the command-line tool gives you a scriptable binary that runs anywhere, including on a server, and can be wired into a build or a batch job. If you need repeatability across many files, the CLI is the better shape. If you need to look at the result and adjust cropping by hand, the app is.

FFmpeg is the other comparison people reach for, and the difference is in the palette strategy. FFmpeg can produce GIFs, but the README's description of Gifski is specifically about pngquant's cross-frame palettes and temporal dithering, which is the part that determines whether a gradient bands. FFmpeg also handles WebM, which Gifski does not, so for WebM sources FFmpeg is the entry point either way. The README's own PNG-sequence recipe uses both: FFmpeg to build the intermediate ProRes file, Gifski to encode the GIF.

Browser-based converters are a third option. They require uploading your video to someone else's machine, which is a different trade-off entirely, and they do not give you the local editor's controls over dimensions, speed, cropping and looping.

Maintenance, distribution and licence

The repository is not archived, and the last push was on 2026-09-11. The most recent release listed is v3.0.6, dated the same day, with v3.0.4 on 2026-07-08 and v3.0.3 on 2026-07-01 before it. That is a recent release cadence, and the version numbers suggest a stable 3.x line rather than churn.

The project is MIT licensed. That matters for the source in this repository, but the app you install from the Mac App Store is a signed, sandboxed distribution, and the non-App Store build is a separate zip that the README says will not receive automatic updates. If you are shipping Gifski as part of a commercial workflow, the MIT licence covers the code, but the App Store build's terms are a separate question. This is not legal advice; read the licence file and the App Store listing.

The upgrade cost is mostly the macOS floor. The App Store version requires macOS 26 or later, so machines on older releases must use one of the archived zips, and those do not move forward. The README also states the project does not plan to localize the app, so a non-English interface is not on the roadmap. The commented-out batch conversion section in the README suggests the Shortcuts route was considered and is not currently documented, which is worth knowing if you were counting on it.

Editorial conclusion

Adopt Gifski if you are on macOS 26 or later and want a drag-and-drop path from a short screen recording or clip to a shareable GIF without touching a command line. Do not adopt it if you need Windows or Linux, WebM input, batch conversion inside the app, or a headless pipeline; the README points those cases at the cross-platform command-line gifski tool instead. Before installing, check your macOS version against the requirement, and confirm your source file is a format macOS supports, since QuickTime Animation is explicitly not supported.

Frequently asked questions

Official sources

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