What the GIFvideo → gif, the way creatives need it
gif maker for linux

A GIF Maker for Linux With Nothing to Install

You already have the best GIF pipeline ever written and it lives in ffmpeg. This is for the times when you would rather see the file size before you commit to it.

Drop a video, get a GIF free · frame-perfect · nothing leaves your browser Open the converter →

How to make a GIF on Linux without installing anything

What the GIF does the whole thing locally, right in your browser: nothing here ever leaves your machine.

  1. Open your existing browser. Firefox or Chromium, whichever shipped with your distro. Load What the GIF. No repository, no Flatpak, no AppImage, no dependencies.
  2. Bring in the clip. Drag a file from your file manager onto the page, or use Record a Tab to capture another tab, window, or screen through the browser's own share picker.
  3. Trim against a live preview. Drag the in and out points against the picture, then use the arrow keys for frame-level correction until the loop closes cleanly.
  4. Dial in fps, scale, and colors. Choose a frame rate around 10 to 15 for interface footage, downscale to your target width, and pick a palette size, with quality set to Medium or High for the k-means refinement pass.
  5. Read the estimate before encoding. The projected file size updates as you adjust, so you land under your limit without rendering first. Add Extra Compression at Medium if you need another 30 to 50 percent off.
  6. Export to your download directory. Convert, and the file writes to wherever your browser saves downloads. The source never left the machine, since the whole encode ran locally.

ffmpeg won this argument years ago

Any honest page about making GIFs on Linux has to open here. The canonical answer is two commands, and it is genuinely excellent:

The two-pass structure exists for a real reason. GIF allows 256 colors per frame, so something has to decide which 256. Letting the encoder guess frame by frame produces the muddy, shifting result everyone recognizes; palettegen instead surveys the whole clip first and picks one table that serves all of it. Then gifsicle cleans up afterward, with --lossy if you want to trade a little grain for a lot of bytes.

If those two lines are already in your shell history, close this tab with our blessing. You have the better tool for the job you do.

The part of the two-step that costs you a re-render

The pipeline's weakness is not quality, it is the feedback loop. You choose fps, scale, and palette size blind, wait for the encode, run ls -lh, discover the result is 8 MB against a 5 MB ceiling, and change a number. Then you do it again. Every iteration costs a full render, and if you are chasing a hard limit for a bug tracker or a chat client, four rounds is normal.

What the GIF closes that loop instead of shortening it. A projected output size sits next to the controls and moves while you drag them, so you find the settings that fit before anything encodes. A Play edit button runs the whole assembly, including cuts and captions, through the same pipeline that will produce the file, so the preview is the export rather than an approximation of it.

The trim is the other piece. Both ends snap to genuine frames and the arrow keys step them, all of it against a running preview. Finding the exact frame where an animation completes is a visual problem, and doing it by editing timestamps in a shell command is the slow way to solve it.

No package, no distro question

Nothing installs, which quietly settles a pile of Linux-specific questions before they get asked. There is no .deb and no .rpm, so no repository to add. No Flatpak, no Snap, no AppImage to chmod. Nothing pulls in a runtime, nothing conflicts with your package manager, and nothing needs updating when you next dist-upgrade.

It is a web page, so the distro is irrelevant. Debian, Arch, Fedora, Mint, NixOS, an old Ubuntu LTS on a machine you're afraid to touch: all identical. Wayland or X11 makes no difference either, since the browser handles the display and the tool never talks to it. Firefox and Chromium both run it, which covers whatever shipped as your default.

Record a Tab does work here, unlike on tablets. The browser's native share dialog does the choosing, whether that is one tab, one window, or the whole display, and whatever comes back arrives in the editor as an ordinary clip. It runs at wall-clock speed and cuts itself off after five minutes, but for catching a CSS animation or a web app misbehaving it saves you a trip to a separate capture tool.

How the palette actually gets built here

Since you're the audience that will ask: quantization runs median cut first, then refines the result with k-means (Lloyd's algorithm) over the sampled pixels. Medium quality runs two refinement passes; High runs four and samples frames more densely. Measured against median cut on its own, that lands roughly 9 to 15 percent lower quantization error on gradient-heavy footage at the same file size. Low skips the refinement entirely when you want speed.

A lossless pass runs on every GIF export as well: duplicate frames collapse into one, and what survives keeps only the rectangle that actually changed. Same pixels out, fewer bytes, and no setting to hunt for. Beyond that there is an Extra Compression setting in the same tradition as gifsicle's lossy LZW, at Light, Medium, or Strong, where Medium typically takes 30 to 50 percent off in exchange for mild grain.

None of this beats a tuned ffmpeg command in a benchmark. It is meant to get you a good file without a benchmark.

Keep ffmpeg in your PATH

There are jobs a browser tab has no business touching, and they are the jobs Linux users have most often:

So this is not a replacement, it is a different shaped tool. One clip, a size target you have to hit, and a loop point you need to see: open the tab. Everything else: you already know the command. For the weight-tuning specifics either way, the small-file page and the compression walkthrough get into the numbers.

No install, no incantation

The browser you already have, a trim you can see, and a size estimate that moves before you commit. ffmpeg keeps its place in your PATH.

Open the converter

Keep going

GIF Maker for Windowsgif maker for windows
GIF Maker for Macgif maker for mac
GIF Maker for Chromebookgif maker for chromebook
Compress a GIFcompress gif
High-Quality Video to GIFhigh quality video to gif
Best-Quality GIF Converterbest quality gif converter

Questions, answered

Is there anything to install or a package to add?
Nothing at all. No .deb, no .rpm, no Flatpak, no Snap, no AppImage, and no repository. It is a web page, so your package manager never learns it exists.
Which distros does it work on?
All of them, because the distro is not involved. If Firefox or Chromium runs, the converter runs. Wayland and X11 both make no difference, since the browser owns the display.
Why would I use this instead of ffmpeg?
For the feedback loop, mostly. ffmpeg makes you render before you can see the file size or check the loop point; here both are visible while you adjust. For batches, scripting, headless machines, or unusual codecs, ffmpeg is still the right answer and this page will not pretend otherwise.
How does the color quantization work?
Median cut followed by k-means refinement over the sampled pixels, two passes at Medium and four at High with denser frame sampling. That comes in around 9 to 15 percent lower quantization error than median cut alone on gradient-heavy footage at the same size. Low skips refinement for speed.
Does Record a Tab work on Linux?
Yes, on any desktop browser that implements the capture API. You choose the source from the browser's native share dialog, the frames get assembled inside the page rather than sent anywhere, and it runs at wall-clock speed with a five-minute cutoff.
Does the video get uploaded for conversion?
No. Both the decode and the encode run in your browser against your own CPU. Once the page has loaded you can drop the interface entirely and keep converting, which is about as short a proof as this question admits.