About

Animated GIF files use LZW compression with per-frame delay tables stored in Graphics Control Extension blocks. A typical GIF carries 256-color palette per frame, no audio track, and frame delays quantized to 10ms increments. The format produces files 5× to 20× larger than equivalent H.264/VP9 video at comparable visual quality. Sharing GIFs on platforms that transcode to video (Twitter, Telegram, iMessage) triggers server-side re-encoding that degrades quality unpredictably. Converting beforehand gives you control over output parameters.

This tool parses the raw GIF binary in your browser - reading the Logical Screen Descriptor, decoding each LZW-compressed frame with proper disposal method handling (restoreToBackground, restoreToPrevious, doNotDispose), reconstructing the full-resolution canvas state per frame, then encoding the sequence into a video container using the browser's native MediaRecorder API. No data leaves your device. Limitation: output codec depends on browser support - Chromium produces WebM (VP8/VP9), Safari produces MP4 (H.264). Frame timing accuracy is ±10ms due to GIF spec granularity.

Formulas

GIF frame delay is stored as a 16-bit unsigned integer in units of 1/100 second:

t_frame = delay × 10 ms

Effective framerate:

fps = 1000t_frame

Many GIF encoders use a delay value of 0 (undefined). Browsers interpret this as approximately 100ms (10fps). This converter follows the same convention.

Estimated compression ratio for video output:

R = S_gifS_video ≈ 5 - 20×

Where S_gif = GIF file size in bytes, S_video = output video file size. Actual ratio depends on frame complexity, motion amount, and color distribution.

LZW decompression initializes a code table of size 2^minCodeSize + 2 entries (clear code and EOI code), then builds dictionary entries dynamically as compressed codes are read from the sub-block stream.

Reference Data

Property	GIF	MP4 (H.264)	WebM (VP9)
Max Colors	256 per frame	16.7M (8-bit 4:2:0)	16.7M (8-bit 4:2:0)
Compression	LZW (lossless per frame)	DCT + Motion Compensation	DCT + Motion Compensation
Transparency	1-bit (on/off)	Not supported	Alpha channel (VP9)
Audio	None	AAC, MP3	Opus, Vorbis
Typical File Size (5s, 480p)	2 - 15MB	0.2 - 1.5MB	0.15 - 1.2MB
Min Frame Delay	10ms (100fps max)	Arbitrary	Arbitrary
Browser Decode	Native <img>	Native <video>	Native <video>
Looping	Netscape App Extension block	Player-dependent	Player-dependent
Interlacing	Supported (4-pass)	N/A	N/A
Max Dimensions	65535 × 65535	Codec-limited (~8192p)	Codec-limited (~8192p)
Disposal Methods	4 (none, background, previous, unspecified)	N/A (full frames)	N/A (full frames)
Container Format	.gif	.mp4 (ISOBMFF)	.webm (Matroska)
Patent Status	Expired (2004)	Licensed (MPEG LA)	Royalty-free
Year Introduced	1987	2003	2010

Frequently Asked Questions

The output format depends on your browser's MediaRecorder codec support. Chromium-based browsers (Chrome, Edge, Brave) natively support VP8/VP9 and produce WebM containers. Safari supports H.264 and outputs MP4. Firefox typically outputs WebM. The video content is identical in quality - WebM files play in all modern browsers and can be renamed or remuxed to MP4 with tools like FFmpeg if a strict .mp4 container is needed.

The GIF spec defines four disposal methods in the Graphics Control Extension block: 0/1 (do not dispose - leave frame in place), 2 (restore to background - clear the frame area to the background color or transparency), and 3 (restore to previous - revert to the canvas state before the frame was drawn). This converter implements all four methods by maintaining a compositing canvas and a backup canvas for method 3. Incorrect disposal handling causes visual artifacts like ghosting or flickering - a common bug in naive GIF parsers.

GIF supports 1-bit transparency (a single palette index marked as transparent). MP4/H.264 does not support alpha channels at all. VP9 in WebM can support alpha, but MediaRecorder does not encode alpha in practice. Transparent pixels are composited against a white background by default. If you need transparency preserved, you would need a different output format (e.g., WebM with alpha via a custom encoder, which no browser currently supports via MediaRecorder).

GIF frame delays are stored in 10ms increments. A delay value of 0 is technically undefined - browsers interpret it as ~100ms (10fps). Some GIF editors set all delays to 0 and rely on browser behavior. This converter follows browser convention: delay values of 0 or 1 are treated as 100ms. Additionally, MediaRecorder operates in real-time capture mode, so frame timing accuracy is limited to approximately ±10ms. For GIFs with very fast frame rates (delay = 2, i.e., 50fps), the output may show slight timing drift.

The converter processes everything locally in your browser using JavaScript. No data is uploaded to any server. The practical file size limit is around 50MB, constrained by browser memory allocation for decoding all frames into RGBA bitmaps simultaneously. A 1000-frame 500×500 GIF requires approximately 1000 × 500 × 500 × 4 = 1GB of raw pixel memory. Very large GIFs may cause the browser tab to run out of memory.

Yes. The converter exposes a quality slider that maps to the MediaRecorder videoBitsPerSecond parameter. Higher bitrate produces better quality at larger file size. The default is 2.5 Mbps which is sufficient for most GIF content (typically 256 colors, limited motion). For high-resolution GIFs (1080p+), increase to 5-8 Mbps. Note that the quality parameter affects the video codec compression, not the GIF decoding - all frames are decoded at full fidelity regardless of output settings.