How to Turn Extracted Video Frames into a Good GIF

Why GIFs go wrong at the extraction stage

Most bad GIFs are decided before any GIF software is opened. Someone extracts every frame of a five-second clip, gets 150 images, assembles them, and ends up with a 14 MB file that a chat app refuses to embed. The instinct is then to compress harder, which makes it muddy without making it much smaller.

The actual problem is upstream. A GIF is not a video codec — it has no motion compensation, no inter-frame prediction worth the name, and a hard ceiling of 256 colours per frame. Every frame is close to a standalone image. That single fact drives every decision below.

So the sequence to think in is: decide the frame count first, the palette second, and only then worry about compression.

Step 1: Choose the sampling interval

The question is not "how many frames does the source have" but "how many does the motion actually need". Some rough starting points:

• 10–12 fps — the workhorse setting. Smooth enough for gestures, UI demos, and most reaction clips. On a 30 fps source, that is every 3rd frame; on 60 fps, every 5th.
• 15 fps — for continuous motion where 12 starts to strobe, like a camera pan or a bouncing object.
• 5–8 fps — for slide-like content: a chart building up, a before/after, a slow zoom. Often looks deliberate rather than cheap.
• 24+ fps — rarely worth it. The file size roughly doubles against 12 fps and most viewers cannot tell in a small looping image.

In the frame extractor, use the "Frame Rate (FPS)" mode and enter the divisor: 3 for every third frame, 5 for every fifth. The frame count updates as you type, which is the number that actually predicts your file size.

Step 2: Keep the duration short

GIF has no long-form use case. Two to four seconds covers almost everything that works as a loop, and the loop point matters more than the length: a clip that ends near where it started reads as continuous, while one that cuts mid-motion draws attention to the seam every repetition.

Use the time-range slider to trim before extracting rather than deleting frames afterwards. The timestamps are visible as you drag, so you can land the out point on the same pose as the in point.

Step 3: Understand the 256-colour limit

This is the constraint that surprises people, and it is worth understanding rather than fighting.

Every GIF frame indexes into a palette of at most 256 colours. Your source video has millions. Something has to throw away the difference, and how it does that decides how the result looks.

Two strategies, and the right one depends entirely on the content:

• Dithering scatters pixels of adjacent palette colours to fake the missing ones. Gradients — skies, soft lighting, shadows on a face — survive far better with it. The cost is a visible speckle pattern and a noticeably larger file, because that noise defeats the compression.
• No dithering gives flat, clean colour areas and much smaller files. Ideal for screen recordings, UI demos, line art, anything with large uniform regions. On photographic gradients it produces hard banding.

Practical rule: screen content, no dithering. Camera footage, dithering on. If you are unsure, export both and look at them at actual size — the difference is obvious and it takes a minute.

This is also why extracting to PNG is the right call even though the final GIF has 256 colours. Every JPEG artefact in the source becomes a colour the palette has to spend an entry on. Feeding clean, lossless frames into the palette step gives the quantiser a better starting point.

Step 4: Match frame delay to the interval you extracted

GIFs do not store a frame rate. They store a delay per frame, in hundredths of a second — and this is where a lot of GIFs end up playing at the wrong speed.

The arithmetic is simple: delay = 100 ÷ your target fps.

• 12 fps → delay 8 (0.08s)
• 10 fps → delay 10 (0.10s)
• 15 fps → delay 7 (rounding to 6.67)
• 5 fps → delay 20 (0.20s)

Two things to know. First, the rounding is real: 15 fps cannot be expressed exactly, so the loop drifts slightly. For anything where timing matters, prefer 10, 12.5, 20 or 25 fps, which divide cleanly. Second, most browsers silently clamp delays below 2 (0.02s) up to 10 — so a GIF authored at 50 fps will play at 10 fps for most viewers, at five times the file size and none of the smoothness.

Step 5: Cut the size, in the order that works

If the file is still too big, apply these in order. Each one costs less quality per byte saved than the one after it.

1. Reduce the dimensions. Halving the width quarters the pixel count. A 480-pixel-wide GIF is fine for most embedding contexts; 800+ is rarely necessary.
2. Drop frames. Going from 15 to 10 fps removes a third of the data for a change most viewers will not register.
3. Shorten the clip. Ruthlessly. Almost every GIF has a second at the start or end doing nothing.
4. Reduce the palette below 256. 128 or even 64 colours is often invisible on screen content and meaningfully smaller.
5. Turn dithering off if you had it on and the content can take it.

Notice that "compress harder" is not on the list. GIF's compression is lossless LZW — there is no quality dial. Everything you can do is a decision about what data to include in the first place.

When you should not be making a GIF at all

Worth saying plainly, because it saves a lot of effort:

• Anything over about five seconds. An MP4 or WebM will be a fraction of the size at better quality. Most platforms that accept "GIFs" now convert them to video internally anyway.
• Photographic content with lots of gradient. 256 colours is simply not enough, and no palette trickery fixes it.
• Anything needing audio. GIF has none, and the loop will feel wrong if the source had a beat.
• Anything above 800 pixels wide. By then the size penalty is severe enough that video is the correct answer.

GIF earns its place in exactly one situation: a short, silent, autoplaying loop that must work anywhere without a player. For that, it is still unbeaten — provided the frames going in were chosen deliberately.

A worked example

Say you want a GIF of a three-second UI interaction from a 60 fps screen recording, under 1 MB.

1. Trim to the 3.2 seconds that contain the interaction, with the last frame close to the first.
2. Extract in FPS mode with N = 5 — every fifth frame of 60 fps gives 12 fps, about 38 frames. PNG output.
3. Assemble at delay 8, dithering off (it is screen content with flat colours).
4. Scale to 600 pixels wide if the source was larger.
5. Check the result. Around 38 frames of flat UI content typically lands well under 1 MB. If not, drop the palette to 128 colours before touching anything else.

The whole thing takes a few minutes, and every step is a decision you made rather than a default you inherited.