GIF to WebP Converter

The encoder chooses lossy or lossless compression per frame, which suits animated GIFs well because they are frequently a mixture — flat cartoon frames alongside photographic ones, or a video clip with text captions over it.

• 90–100 — Near-transparent quality. Worth it for animations with text or sharp graphics, and still far smaller than the GIF.
• 70–89 — The useful band. 75 is the default and handles most content well.
• 50–69 — Distinctly smaller. Fine for long clips where size matters more than fine detail.
• Below 50 — Visible softening, especially on text.

An unusual property of this conversion is worth knowing: the result can look better than the source. Normally converting between lossy formats only loses quality. Here the GIF's 256-colour ceiling has already flattened the image, and WebP does not impose one — so while it cannot restore the colours GIF discarded, it will not add banding of its own the way re-encoding to another GIF would.

Transparency is preserved, and improved. GIF transparency is a single on/off bit per pixel, which is why cut-out GIFs have hard, jagged edges. WebP stores 256 levels, so if you later edit the WebP those edges can be softened — though the conversion itself cannot invent smoothness the GIF never had.

Why this conversion is worth doing

• Page weight. A single animated GIF is often heavier than every other asset on a page combined. Converting is usually the biggest performance win available.
• Mobile data. Autoplaying multi-megabyte GIFs on a metered connection is a real cost to your visitors.
• Email and messaging limits, which GIFs exceed easily.
• Storage. A library of reaction GIFs shrinks dramatically.

When to keep the GIF

Compatibility outside the browser is the only real reason, but it is a genuine one:

• Some chat and messaging apps accept GIF only.
• A number of social platforms still expect GIF for animated uploads.
• Older forums, wikis and content systems may not recognise WebP.
• Email clients are inconsistent — GIF animates almost everywhere, WebP does not.

For a website you control, WebP with a GIF fallback covers both:

<picture>
  <source srcset="clip.webp" type="image/webp">
  <img src="clip.gif" alt="…">
</picture>

Should it be a video instead?

Worth asking honestly. For anything longer than a few seconds, an MP4 or WebM video is smaller still — often by another large margin — because video codecs have decades more optimisation behind them and can drop the alpha channel a WebP carries.

WebP wins when you need it to behave like an image: autoplay everywhere without controls, work inside an <img> tag, keep transparency, or paste into places that accept images but not video. For short loops and reaction clips that is usually the right trade.

Still GIFs

Not every GIF moves. A single-frame GIF is treated as an ordinary image and converted normally — you still get the size saving and the escape from the 256-colour palette. If it is a logo or graphic rather than an animation, converting to PNG may suit better.