How Video to GIF Conversion Works
Turning a video into a GIF looks like a single click, but under the hood it is a small pipeline that translates between two very different ways of storing moving pictures. An MP4 stores changes between frames in millions of colors; a GIF stores whole frames in at most 256 colors each. This article walks through each step, using the way Video2GIF does it – entirely inside your browser, with no server involved.
The pipeline at a glance
- Decode the compressed video into actual pictures.
- Sample frames at the GIF frame rate between your start and end times.
- Resize each frame on a canvas, then apply direction and caption.
- Quantize each frame’s millions of colors down to a 256-color palette.
- Map every pixel to its nearest palette color.
- Encode the indexed frames with LZW and write the GIF file with timing and loop information.
1. Decoding the video
A video file such as MP4, MOV or WebM is compressed with a codec like H.264, HEVC or VP9. Most of its frames are not stored as pictures at all – only as motion vectors and differences from a previous keyframe (see What is MP4?). To get a real picture for any moment, a decoder has to start at the nearest keyframe and rebuild every frame up to that point.
Video2GIF lets the browser’s own <video> element do this. Browsers have highly optimized, often hardware-accelerated decoders, so there is nothing to download or install, and any format your browser can play can be converted. This is also why a format like AVI or WMV may not open: if the browser cannot play it, it cannot decode it.
2. Sampling frames
A phone video usually runs at 30 or 60 frames per second. A GIF at that rate would be enormous, so the converter samples the video at the frame rate you choose – 10 fps by default. For a clip from 2.0 s to 5.0 s at 10 fps it seeks to 2.0, 2.1, 2.2 … 4.9 seconds and captures the picture at each point: 30 frames in total.
Speed changes are applied here, not by changing the playback: at 2× the converter samples twice as far apart in the source while keeping the same delay per GIF frame, and at 0.5× it samples twice as densely. Reverse simply reverses the captured list; boomerang appends the reversed list (minus the duplicated end frames) to the original.
Each frame’s display time is stored in the GIF as a delay in hundredths of a second. 10 fps becomes a delay of 10, 12 fps becomes 8 (rounded from 8.33), which is why GIF frame rates are always approximate.
3. Resizing and drawing
Each captured frame is drawn onto an HTML canvas at the target width (480 px by default), with the height scaled to keep the aspect ratio. Resolution has the biggest effect on file size – halving the width cuts the pixel count, and roughly the file size, by four. The canvas then gives back the raw pixels: four bytes (red, green, blue, alpha) per pixel. These raw frames are kept in memory; direction (reverse, boomerang) and any caption are applied to copies of them just before encoding.
4. Color quantization: from millions of colors to 256
This is the heart of the conversion and where most of the quality is won or lost. A single 480×270 video frame can easily contain tens of thousands of distinct colors, but a GIF frame can only use 256. Color quantization finds the 256 colors that best represent the frame.
Video2GIF uses the gifenc library’s quantizer. It first reduces each pixel to a coarser color space (RGB565 – 5 bits red, 6 green, 5 blue – or RGB444 for the 64-color “Small file” setting) and builds a histogram of how often each color appears. It then repeatedly merges the closest pairs of color clusters, weighted by how many pixels they cover, until only 256 (or 128, or 64) remain. Colors that cover large areas – sky, skin, a UI background – keep accurate representatives, while rare colors are absorbed into their nearest neighbours.
Crucially, this is done separately for every frame. Each frame gets its own color table (the first one is written as the file’s global table, every later frame carries a local color table), fitted to what is on screen at that moment. A single global palette for the whole clip would have to cover every scene at once and would look visibly worse whenever the picture changes.
5. Palette mapping
With a palette chosen, every pixel is replaced by the index of the closest palette color (the smallest distance in RGB space). The frame is now a grid of small numbers from 0 to 255 – exactly what a GIF stores.
Some converters add dithering at this point, scattering pixels of two palette colors to fake a third. Dithering hides banding in gradients but adds noise that changes from frame to frame, which both shimmers in animation and makes files much larger because the noise compresses badly. With per-frame palettes the banding is usually mild enough that skipping dithering gives a cleaner, smaller GIF.
6. LZW encoding and writing the file
Finally, each indexed frame is compressed with LZW. The encoder reads the pixel indices in order and builds a dictionary of sequences it has already seen; when a sequence repeats it writes one short code instead of the whole run. Flat areas compress extremely well, noisy footage much less so.
The encoder writes the GIF header, the NETSCAPE2.0 loop block (repeat count 0 = loop forever; for “Play once” the block is left out), and then for each frame a graphic control block with the delay, the local color table and the LZW data. The encoding runs in a Web Worker – a background thread – so the page stays responsive and the progress bar keeps moving.
Because the decoded frames are kept in memory after the first pass, removing frames in the key-frame strip or changing the caption skips decoding and sampling and only repeats quantization and encoding. That is why “Rebuild GIF” is much faster than the first conversion.
Why the GIF is bigger than the video
Steps 1 and 6 explain it. The MP4 stored mostly differences and motion; the GIF stores every frame as a full picture with comparatively simple compression. A 1 MB MP4 becoming a 5–10 MB GIF is normal. The levers you control, in order of impact, are: width, clip length, frame rate, and number of colors.
The reverse: how GIF to MP4 works
The GIF to MP4 converter runs the pipeline backwards:
- The GIF is parsed and each frame is decompressed from LZW back to palette indices, then to full-color pixels.
- Frames are composited in order, honouring each frame’s position and disposal method, so partial-update frames become complete pictures. Transparent pixels are filled with the background color you pick, since H.264 has no transparency.
- The finished frames are passed to the browser’s WebCodecs
VideoEncoder, which compresses them with H.264 – usually using the device’s hardware encoder. - The encoded stream is wrapped in an MP4 container with the correct timestamps for each frame’s delay.
Because H.264 uses motion prediction and is not limited to 256 colors, the resulting MP4 is often many times smaller than the GIF it came from – which is exactly why social networks convert uploaded GIFs to video.
Why do it in the browser?
- Privacy – your video never leaves your device.
- Speed – no upload or download of a large video file, no server queue.
- No limits – the only limit is your device’s memory, not a server quota.
Ready to try it? Open the video to GIF converter, or learn more about the GIF format.