Gifski, a Mac front end for the gifski encoder

The Mac app wraps the gifski encoder, not the other way round

Two different things share the name. `gifski` is the encoder, a high-quality GIF encoder library with a command-line tool of its own. Gifski is the macOS app built around it, and its repository is Swift.

The app adds what a library cannot offer: a window, a Share extension, a Services entry, progress reporting in the Dock icon through DockProgress, and settings persistence through Defaults, described as a swifty and modern UserDefaults.

The repository layout says the same thing. `Gifski/` holds the app target, `Gifski.xcodeproj/` the Xcode project, `Share Extension/` the share sheet component, with `gifski-api/`, `Tests/` and `Stuff/` alongside. `Config.xcconfig` carries build settings, `.swiftlint.yml` carries the lint rules, and `contributing.md` and `maintaining.md` sit next to the code. `app-store-description.txt` and `app-store-keywords.txt` mean the store copy is version controlled too.

The consequence for anyone expecting a cross-platform tool is immediate. The app is Mac only, and the project's own answer to requests for Windows and Linux is a separate cross-platform command-line tool linked from its FAQ, not a build of this repository.

Cross-frame palettes from pngquant, and gifsicle when you want a small file

The high-quality path runs through pngquant. The encoder uses pngquant's fancy features for efficient cross-frame palettes and temporal dithering, which is what lets a single frame carry thousands of colors. The result runs at up to 50 FPS.

The low-quality path is a separate tool. The Quality slider, listed among settings alongside dimensions, speed, frame rate, cropping and looping, produces smaller and lower quality GIFs thanks to gifsicle. So the file size lever is one slider and one external encoder, not a general compression setting.

Neither path escapes the format. The project's own FAQ entry states that the GIF image format is very space inefficient, that it works best with short video clips, and that the fix is to reduce the dimensions, FPS or quality.

The practical consequence is that a full-length screen recording at large dimensions is the worst case for this app, and no setting inside Gifski makes long footage small. Short clips, and lower dimensions, FPS or quality: those are the levers the FAQ names.

50 FPS is the ceiling because browsers throttle anything higher

Fifty frames per second is the top of the range, and the reason is a browser behaviour rather than an encoder limit. The FAQ entry on higher frame rates says browsers throttle frame rates above 50 FPS and play them at 10 FPS, with the discussion linked to an issue in the repository.

That detail matters more than it first appears. A GIF exported at 60 or 120 FPS does not play at 60 or 120 in a browser. It plays slower than the 50 FPS version would, so the extra frames cost bytes and buy a worse result. The frame rate setting is a ceiling imposed by the destination, not a quality dial you can push.

The consequence for anyone exporting a loop to show design work is that anything above 50 is a downgrade dressed as an upgrade.

ProRes 4444 XQ instead of QuickTime Animation, and no WebM at all

Format support follows macOS rather than the encoder. Gifski supports all the video formats macOS supports, so .mp4 and .mov with H264, HEVC or ProRes all work. WebM does not, because macOS does not support WebM, and the suggested route is converting the video to MP4 with another app first.

QuickTime Animation is the interesting exclusion, since Gifski does not support it. The guidance is to use ProRes 4444 XQ instead, on three grounds: it is more efficient, it is more widely supported, and, like QuickTime Animation, it supports the alpha channel. That third property is the one that decides the case when the source footage has transparency, which is why the ProRes route is a deliberate choice rather than a fallback.

The consequence shows up at import time. A QuickTime Animation file will not open in Gifski, so the check to run before exporting a batch is one open in the app itself, not a look at the file extension.

Bounce playback doubles the frames and the file size

One option trades size for motion: bounce playback, also called yo-yo. The generated GIF plays forward and then backward, an effect the project compares to the bounce effect in iOS Live Photo effects. The cost is stated in the feature description rather than left to be discovered: the option doubles the number of frames in the GIF, so the file size doubles as well.

That doubling lands on top of a format that already handles size badly, which makes a bounce loop the most expensive thing this app can produce per second of footage. It earns its cost when the reverse pass is the point of the animation, and wastes it when the reversal is decoration.

Nothing in the feature description offers a way to apply the bounce to part of a clip, so the doubled frames are paid across everything being exported. Turning it on for a two-second reveal and leaving it on for a thirty-second export is the same click and a very different file.

Three ways in: the Share menu, the Services menu, a Finder Quick Action

Three entrances reach the converter without hunting for the file. The share extension takes videos from the Share menu of any macOS app, and a macOS screen recording can go straight in by clicking the thumbnail that appears once recording stops and choosing Share from there. A system service puts conversion in the Services menu of any app that offers a compatible video file. A Finder Quick Action converts from Finder itself without opening Gifski at all, and you can create several shortcuts carrying different settings, such as quality, dimensions or looping, to match different jobs.

The Quick Action route has a catch worth reading twice: it requires the TestFlight version of Gifski, not the App Store build.

Two smaller things are given as tips. After a conversion, Command+C copies the GIF and Command+S saves it. In the width and height input fields, the arrow up and down keys change the value by 1, and holding Option changes it by 10.

Concurrency is where the app gives up. Running several conversions at the same time is not supported inside the app. The stated alternatives are the Shortcuts app, using the shortcut action that comes with the app, or launching separate instances with `open -na Gifski`. That second route carries its own warning: do not leave the editor view open in more than one instance, because changing the quality in one changes it in all of them.

A PNG sequence has to become ProRes before Gifski can see it

The app does not read a folder of still images. To convert a numbered PNG sequence, the documented route detours through FFmpeg and a ProRes intermediate, then hands the result 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 filename pattern matters, because FFmpeg is being asked for numbered input: images named in the format `image_000001.png`, with `-framerate` adjusted to match the real frame rate rather than left at the example value. The intermediate is a temporary .mov written with `prores_ks` and `-profile:v 5`, and the last part of the line opens Gifski on it.

So a design export in numbered PNGs costs an FFmpeg install, a temporary ProRes file, and one extra conversion step before the app does anything. FFmpeg shows up here as a dependency rather than a competitor.

macOS 26 for the current build, older zips for older systems

Getting the app starts with a platform decision. The current build requires macOS 26 or later and comes from the Mac App Store. Older builds are linked for the systems that cannot run it: 2.23.0 for macOS 13 and later, 2.22.3 for macOS 12 and later, 2.21.2 for macOS 11 and later, 2.20.2 for macOS 10.15 and later, 2.16.0 for macOS 10.14 and later, and 2.4.0 for macOS 10.13 and later.

A separate non-App Store version exists for people who cannot reach the store, and it carries a specific cost: it receives no automatic updates, and the project says it updates that build about once a year. On the current timeline, v3.0.6 was released on 2026-09-11, v3.0.4 on 2026-07-08 and v3.0.3 on 2026-07-01, and the repository's last push was on 2026-09-11.

Building it yourself needs Rust installed before Xcode is opened, and the project's own build instructions are these three commands:

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

The licence is MIT. Localizations are explicitly not planned, so the interface ships in the language it was written in.

Editorial conclusion

Gifski is the right pick for a Mac user who needs a smooth, many-color GIF from a short clip and values frame rate over file size, and the wrong pick for anyone batching long footage, working on Windows or Linux, or needing WebM input. Before installing, check the macOS 26 requirement against your machine, decide whether the App Store build or the non-App Store zip suits your update path, and open one source file in the app before exporting a batch, since QuickTime Animation files are not supported.

Frequently asked questions

Official sources

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