Convert GIF to WebP without losing a frame or a color

Why gif to webp is the one conversion with no downside

Almost every format conversion is a trade. This one is not. An animated WebP holds everything an animated GIF holds — the same frames, the same order, the same delays, the same transparency — and it holds it in a fraction of the bytes. There is no palette to squeeze into, no colors to throw away, no soft edge to harden. Two files measured through this page: a 24-frame 320 by 240 animation of flat graphics went from 63,336 bytes to 6,730, and a 30-frame photographic one from 604,994 bytes to 151,630. In both cases the original and the result play identically, side by side, on this page.

That is worth stating plainly because the sibling page on this site, converting WebP back to GIF, has to spend most of its words explaining what the conversion costs. Going this way there is nothing to explain away. The only two honest caveats are further down: what will not accept a WebP, and how close a browser-side encoder gets to a command-line one.

GIF and WebP, in brief

GIF

Full name	Graphics Interchange Format
Extension	.gif
Format type	Lossless raster image, 256 colors, animatable
MIME type	image/gif

WebP

Full name	Web Picture format
Extension	.webp
Format type	Lossy or lossless raster image, with alpha
MIME type	image/webp

What actually happens to the frames

A GIF almost never stores whole pictures. It stores a first frame and then, for each one after it, a rectangle of pixels plus an instruction about what to do with the previous rectangle afterwards — leave it, erase it, or put back what was underneath. Getting that bookkeeping wrong is the classic failure of GIF tools, and it does not look like a bug in the reader: it looks like the moving part smearing across the frame instead of moving. So the first thing that happens here is that every frame is composited into a complete picture, exactly the way a browser draws it, honoring the disposal method the file asked for.

Then each of those pictures is handed to your browser's own WebP encoder, one at a time, and the resulting bitstreams are written into a WebP container this page builds itself. That is the part that used to be considered impossible without a WebAssembly encoder, and the reason it is not: an animated WebP is a container full of ordinary still images. Every frame in it carries exactly the kind of bitstream that sits inside a plain .webp file. Nothing has to be invented — the frames only have to be labeled with their position, their duration and their blending rule, and written in order.

One refinement matters more than everything else for the file size. From the second frame on, only the rectangle that actually changed since the previous frame is encoded, and it is written with the instruction to replace that rectangle outright rather than blend over it. Replace, not blend, is not an arbitrary choice: a GIF frame that erases something has to be able to erase it, and blending can only ever add. The gain was measured by switching the rectangles off in the built page: the same 24-frame animation came out at 14,372 bytes without them and 6,730 with. Where every pixel changes in every frame — a photographic animation, a full-screen fade — no rectangle can be reused and the trick earns nothing.

Every frame is written lossless, and there is no quality slider

This is the decision most likely to look like an omission, so here is the measurement behind it. A GIF frame is drawn from a table of at most 256 colors. Lossy WebP is a video codec at heart, built for photographs and gradients, and flat or dithered 256-color material is close to the worst input you can hand it. The 24-frame graphics animation came to 6,730 bytes written lossless and 106,578 bytes at quality 0.92 — sixteen times larger, and larger than the GIF it came from. On the photographic animation the comparison does turn around, but only by 17 percent: 151,630 lossless against 126,142 at 0.92, paid for with exactness on a file that never had more than 256 colors per frame in the first place.

A control that costs sixteen times on the ordinary case to save a sixth on the rare one is not a choice worth offering, so the frames are always written lossless. What is offered instead is a check: the page probes your browser's encoder by writing a square of random noise at quality 1, decoding it again and comparing every byte. If they match, lossless is available and that is what your frames get. If they do not, the page says so in plain words and falls back to quality 0.92 rather than pretending. Either way you are told which of the two happened, on the receipt, before you download anything.

Shrinking the picture does not shrink the file

Every GIF tool offers a width control, because for a GIF it works: fewer pixels means fewer palette lookups to compress. Carrying that instinct across to WebP produces a surprise, and it is measured rather than argued. Resampling a 256-color picture to three quarters of its width invents colors it never contained — on the test file, the first frame went from 66 distinct colors to 253 — and a lossless encoder pays for every one of them. Measured with libwebp's own encoder on those resampled frames, the result came out about 30 percent larger than at full width. Smaller picture, bigger file.

So there is no width control here, and no frame-dropping control either. Both are GIF techniques for a GIF-sized problem, and this conversion has already solved that problem several times over. If your GIF genuinely has to remain a GIF and still get smaller, that is a separate job on a separate page: squeezing a GIF down to a byte limit searches for the combination of settings that lands under your number and tells you which ones it had to spend.

Timing: the one thing that can legitimately change

A GIF measures its delays in units of one hundredth of a second, and then a second rule sits on top of that coarseness: ask for zero or one unit and every browser gives you ten instead. That substitution was settled in the mid-1990s, an enormous number of files quietly depend on it now, and no vendor will touch it. So a GIF whose frames request one hundredth of a second does not play at 100 pictures per second anywhere — it plays at 10.

WebP has no such rule. Its durations are plain milliseconds and it can express what the file literally says. That leaves a real choice, and it is the only setting on this page that changes a pixel of output timing: match what you have been watching, or write the numbers as the file states them. The default is what browsers play, because that is the animation you decided to convert. The alternative appears only when the two differ, with both totals in milliseconds next to each other, and it exists for the case where the author really did mean 10 milliseconds and only the format was in the way.

Where WebP still is not welcome

Email is the gap that matters. Outlook on Windows does not render WebP at all, and a fair number of mail gateways strip or rewrite images they do not recognize, so an animation that has to survive a mail server is still safer as a GIF. Beyond email the list is short and shrinking: some older forum software, a handful of presentation programs, the occasional internal wiki running a version nobody has touched in years. Everything else — every current browser, iOS and Android, every major chat and social platform — has read WebP for a decade. If you want the longer version of who supports it and why it took so long, what the WebP format actually is covers the history and the two bitstreams inside it.

If you land on one of the holdouts, the way back is on this site and it keeps every frame: WebP to GIF takes the container apart the same way this page builds it. And if the destination will accept video rather than an animated image, GIF to MP4 is smaller still than WebP for anything long or photographic, at the cost of transparency, which H.264 cannot express at all.

How close this gets to a command-line encoder

Close, and the remaining gap belongs in writing rather than in the small print. The encoding is done by your browser, one frame at a time, which means there is no shared palette across frames, no encoder method to tune and no motion search between frames. libwebp's own img2webp, given exactly the same composited frames, produced 5,686 bytes where this page produced 6,730 — 18 percent larger. On the photographic animation, where every pixel moves in every frame and the rectangle trick has nothing to work with, the gap widens a long way: 82,600 against 151,630, which is 84 percent larger. Both numbers belong here. Quoting only the flattering one would be the sort of reporting this site is built to avoid.

That range is the price of not uploading your file, and it is a price worth naming rather than hiding. Nothing on this page reaches the network after the page itself has loaded: the GIF is read in the tab, the frames are composited in the tab, the encoder is the one already built into your browser, and the container is assembled by code you can read. If you have ever wondered what happens to a file you upload to a converter, the answer here is that there is nothing to wonder about, because the file never leaves.

What this page does not do

It does not crop, rotate, resize, caption, shuffle frames or change playback speed. A still GIF converts perfectly well, and the page says out loud that it found a single frame rather than quietly handing back an animation of one. A truncated GIF — the usual sign of a download that was cut off — is read as far as the bytes go, and the number of frames that were recoverable is reported instead of the whole file being rejected. And nothing is refused for being large: you get told what a file that size will cost your tab before the work starts, and then the work starts anyway. If you need to build an animation rather than convert one, video to GIF is the page that makes frames out of a clip.