Initializing... drag & drop files here
Supports: GIF
The GIF format dates to 1987 (GIF89a added animation in 1989) and stores each frame as an LZW-compressed palette of up to 256 colors. That palette ceiling is why a 5-second screen recording can balloon past 10 MB while the same clip as MP4 is under 500 KB — GIF was never designed for the long, photographic, high-frame-rate content people now post to it. Compression buys you back the bulk of that overhead.
| Property | GIF | MP4 (H.264) | Animated WebP |
|---|---|---|---|
| Max colors per frame | 256 | 16.7M (24-bit) | 16.7M (24-bit) |
| Transparency | 1-bit (on/off) | None | 8-bit alpha |
| Audio support | No | Yes | No |
| Typical 5 s, 480p file size | 3-8 MB | 200-500 KB | 0.5-2 MB |
| Auto-play in email clients | Yes | No | No (rendered as static) |
| Browser support | Universal | Universal | Chrome 32+, Firefox 65+, Safari 16+, Edge 18+ (~96%) |
| Auto-loops without controls | Yes | Needs autoplay loop muted |
Yes |
| Best fit | Email, emoji, simple loops | Long clips with audio | Modern web pages |
Per Google's own measurements, lossy animated WebP averages 64% smaller than the equivalent GIF, and lossless WebP is still 19% smaller. For most messaging and web use the size win is dramatic — see GIF to WebP for converting away from GIF, or GIF to MP4 for chat-app-friendly video.
| Method | Typical size reduction | Visible quality cost | When to use it |
|---|---|---|---|
| Lossy LZW (quality 75%) | 30-50% | Slight dithering | Default — works for nearly everything |
| Color palette to 64 | 40-60% | Banding on photos, fine on UI/illustrations | Screen recordings, line art |
| Color palette to 32 or below | 60-80% | Visible banding | Pixel art, monochrome loops |
| Drop every 2nd frame | ~50% | Choppier motion | Static-camera screencasts, slow loops |
| Resize 100% to 50% | ~75% | Smaller dimensions | GIF will be displayed small anyway |
| Combine lossy + color + resize | 85-95% | Some quality loss | Aggressive Discord/email targets |
Stacking methods compounds — resizing to 50%, dropping every other frame, and reducing to 64 colors can take a 12 MB original under 500 KB while still reading clearly at chat-thumbnail size.
Discord enforces a 256 KB cap on animated server emoji. Start by resizing to 128×128 px (Discord's emoji display size), reduce the color palette to 32-64 colors, and drop the quality to 50-60%. Most source GIFs fit under 256 KB after that combination. If it's still too large, shorten the clip — 1-2 seconds is the practical sweet spot for emoji.
GIF's 256-color-per-frame palette and LZW encoding are fundamentally less efficient than H.264 or VP9 video. Even a maximally compressed GIF will almost always be several times larger than the source MP4. If you have a choice, embed an MP4 or animated WebP instead — see Video to GIF for the reverse direction when you specifically need GIF output.
Both. GIF's native LZW step is lossless, but tools (including XConvert and gifsicle's lossy LZW encoder) re-quantize colors and dither pixels before re-encoding to gain 30-50% more reduction. The "lossy" label refers to that pre-processing step, not the LZW pass itself. The quality slider on this page controls how aggressive that pre-processing is.
64 colors is a strong default for UI screencasts — most application interfaces use a limited palette anyway, so dropping from 256 to 64 typically halves size with no visible change. Drop to 32 if the UI is mostly grayscale or two-tone. Keep 128-256 if your recording includes photographic content like a video thumbnail or a webcam overlay.
No. GIF transparency is 1-bit (a pixel is either fully transparent or fully opaque) and that flag is preserved through compression. Be aware though that anti-aliased edges on the original transparent layer can look harsher after color reduction, because the dithering pass has fewer colors to blend with. If you need smooth edges over arbitrary backgrounds, animated WebP's 8-bit alpha channel handles that case better than GIF.
For a 5-second 480p clip: down to about 30-40% of original size with quality alone, to 10-20% by also dropping colors to 64 and frames to every other, and to under 5% by resizing to 50%. Beyond that you'll see clear banding, choppy motion, or pixelation. The fastest test: compress, view, then decide if the artifacts are acceptable at the size you'll actually display.
Two reasons. First, GIF is a tile-based format — animations with more pixel-level change between frames produce larger files even at the same quality setting because more LZW dictionary entries are needed. Second, dithering is content-dependent: noisy footage dithers heavier than flat UI captures. The same quality slider produces different absolute sizes per source clip.
XConvert accepts GIF files up to 300 MB each in a single batch, and there's no cap on the number of files per session. Files are uploaded over an encrypted connection and processed on our servers, so very large files may take a moment to upload — and they are deleted from our servers automatically after one hour.
If your destination supports it, yes — that's usually the better answer. Modern social platforms (Twitter, Reddit, Discord embeds) silently convert uploaded GIFs to MP4 anyway. Email, Slack threads, and animated emoji still need real GIFs. If the latter is your case, compress here; if the former, convert with GIF to MP4 or GIF to WebP for dramatically smaller files at the same visual quality.