Can WebP Be Animated? Yes, and It Beats GIF

Can WebP be animated? Yes, and it beats GIF at the job. WebP supports full animation in both its lossy and lossless modes, converting an animated GIF to lossy WebP cuts the file about 64 percent and to lossless WebP about 19 percent, and it carries real 8-bit alpha transparency through every frame, something GIF has never managed.

I work with WebP daily through the compression engine behind imagecompressor.tools, and animation is the part of the format most people never learn. This guide is part of the WebP and AVIF hub and covers how the frames are stored, what the savings actually look like on a real file, whether transparency survives, which browsers play it, and every way to make one, consolidated in a single place instead of scattered across a tool page, a forum thread, and Google's docs.

Can WebP Be Animated? The Direct Answer

Yes. WebP is a full animated-image format, not just a smaller replacement for JPEG. A single WebP file can hold many frames that play in sequence and loop, the same way a GIF does, and one file can even combine lossy frames, lossless frames, and transparency together (Google Developers, WebP).

The confusion is understandable. Most people first meet WebP as the format their browser downloads instead of a JPG, so they file it away as "the still-image thing that is smaller." Animation was part of the format's design from early on, but it lives in the parts of the spec nobody reads unless they are building an encoder. The practical result is a format that does everything GIF does, does it with better color and smaller files, and adds real transparency GIF cannot touch. The rest of this page is the detail behind that claim.

How Does Animated WebP Store Its Frames?

Animated WebP stores its frames one of two ways, depending on whether the animation is lossy or lossless, and a single file can mix both. That flexibility is the mechanical reason it outperforms the older formats, so it is worth understanding before comparing sizes.

Lossy animation uses a VP8 bitstream

A lossy animated WebP packs its frames into a VP8 bitstream, the same video-derived codec WebP's still-image lossy mode is built on. Each frame is compressed the way a lossy WebP photograph is compressed, throwing away the fine color detail your eye does not track, which is exactly why the lossy mode produces such small files. Because the codec came from video, it is good at the kind of frame-to-frame redundancy short loops are full of.

Lossless animation uses ANIM and ANMF chunks

A lossless animated WebP instead uses two container pieces. An ANIM chunk holds the animation's overall description, its background color and loop count, and a series of ANMF chunks each carry one frame's image data and its display timing (MDN, image file types). Looping is native to both modes, so nothing external has to run a script to make the animation repeat. The frame-timing values live inside those chunks, which is how a WebP animation controls how long each frame stays on screen, the same lever GIF exposes as "frame delay."

One file can mix lossy and lossless frames

The unusual part is that a single animated WebP can combine lossy and lossless frames in the same file. A sharp lossless logo frame can sit in the same animation as heavily compressed lossy photographic frames, and each is encoded with whichever mode suits it. GIF and APNG cannot do this; they pick one approach for the whole file.

How Much Smaller Is Animated WebP Than GIF?

Noticeably smaller in both modes, and the lossy mode is the larger win. Converting an animated GIF to lossy WebP cuts the file about 64 percent; converting the same GIF to lossless WebP instead cuts it about 19 percent (Google WebP FAQ). Both are real savings. Lossless keeps every pixel exactly, so it cannot discard the color data that lossy mode drops, which is why its cut is smaller.

A worked example on a real-size file

Numbers land better on an actual file, so run them on one. Take a 2.4 MB animated GIF, a common size for a short product-demo loop. Apply the published 64 percent cut directly and the lossy WebP lands around 0.86 MB, roughly 864 KB. Apply the 19 percent cut and the lossless WebP comes back around 1.94 MB. Same source, same motion, and the lossy file is under a third of a megabyte away from being one quarter the original size. That gap is the whole webp animation file size argument in one line: the format was built to do what GIF does using far fewer bytes.

Your own files will not hit these percentages to the decimal, because the saving depends on how much color and motion the GIF held, but the direction is reliable: lossy WebP roughly a third the size, lossless a meaningful trim. If you are shipping a still frame or a poster image alongside the animation rather than the loop itself, compress that single frame as WebP here, where the same lossy-or-lossless choice applies one image at a time.

Animated WebP vs GIF vs APNG

Animated WebP beats both older animated formats on the columns that matter, color depth, real transparency, and file size, while GIF and APNG each give up at least one of those. Laying the three side by side is the fastest way to see why WebP has quietly replaced GIF on most modern sites.

GIF's 256-color palette is the format's real ceiling. Smooth gradients and photographic color get dithered or banded to fit inside 256 colors, a cost neither animated WebP nor APNG pays. APNG fixes GIF's color and transparency limits but keeps GIF's all-lossless approach, so it never reaches WebP's lossy mode or the size cut that comes with it. In the animated webp vs gif matchup there is no column where GIF wins on merit; GIF wins only on reach, because it plays literally everywhere, which is the one thing the next sections are about.

Does Animated WebP Support Transparency?

Yes, the same 8-bit alpha channel that still WebP images use carries through every frame of an animation. Animated WebP combines 24-bit RGB color with an 8-bit alpha channel per frame, so each frame can be fully transparent, fully opaque, or any of the 254 values between, exactly like a single transparent WebP image repeated across the sequence.

Why GIF edges look jagged and WebP edges do not

The difference is easiest to feel at the edges of a shape. GIF transparency is binary, a single on-or-off flag per pixel: a pixel is either fully see-through or fully painted, with nothing in between. That is why a GIF logo placed on a colored background so often shows a hard, jagged fringe, the anti-aliased soft pixels around a curve have no way to be half-transparent, so they get forced to one extreme or the other, usually against a background color baked in when the GIF was made.

An 8-bit alpha channel gives every pixel 256 levels of transparency instead of two. The soft pixels around a curve can be partly transparent, so the shape blends cleanly against any background color, and an element can fade or dissolve in and out through actual alpha blending. An animated WebP sprite, icon set, or UI flourish drops onto a dark theme or a photo without a halo; the equivalent GIF usually needs a matching background baked in ahead of time and still shows its edges.

Which Browsers Play Animated WebP?

Every major browser now plays animated WebP, though animation support landed later than basic still-image WebP in some of them, so an old browser that shows static WebP fine might still refuse to animate one. Animation is tracked as its own capability in the support tables for exactly that reason (Can I Use, WebP).

Those thresholds come from Google's own support notes, with Safari the last of the group to arrive at version 14, which shipped with iOS 14 and macOS Big Sur. Anything older than the versions above either falls back to a single static frame or fails to render the image at all, depending on the browser. So the practical rule for webp animation browser support is simple: on any current browser you are safe, and if a meaningful slice of your traffic runs old software, ship a GIF fallback or a static poster image alongside the WebP source rather than assuming universal playback.

How Do You Make an Animated WebP?

You make one with an online converter, an image editor with the right plugin, or a command-line tool, in roughly that order of effort. Page one of the search results splits these across a tool, a forum answer, and Google's developer docs, so here they are in one ladder from no-install to full control.

The no-install route: an online GIF-to-WebP converter

The fastest path is an online converter that takes a GIF or a stack of frames and outputs an animated WebP, handling the frame timing and loop count for you. This is the right choice when you already have a finished GIF and just want the smaller WebP version, which is the most common case. It needs nothing installed and takes seconds. The tradeoff is that you get the converter's default encoder settings rather than fine control over per-frame quality.

The editor route: Photoshop with the WebPShop plugin

Photoshop does not export animated WebP on its own, but the free WebPShop plugin from the WebP project adds it. Once installed, it saves WebP through the normal export path, and you build the animation from a layer-named frame sequence the plugin reads as animation frames (WebPShop plugin, WebP project). This is the route when the animation does not exist yet and you are designing it frame by frame, since you get Photoshop's full toolset before the export.

The command-line route: Google's own utilities

For automation or batch work, Google's WebP toolkit includes utilities for viewing, muxing, and animating WebP images, building an animated file from individual frames or inspecting an existing one. Command-line tools like ffmpeg can also emit animated WebP directly, which is how developers script GIF-to-WebP conversion at scale rather than doing it one file at a time. This route has the steepest learning curve and the most control, and it is the one the forum threads on this topic mostly discuss.

What Are the Disadvantages of Animated WebP?

The real disadvantages are editing-tool support and one-way conversion, not the format's technical quality. WebP wins on color, transparency, and size, so its weak spots are all about the ecosystem around it rather than the frames themselves.

Editing and preview support still lags

Plenty of older or lightweight image editors and preview tools open a static WebP but cannot open or edit an animated one, and some design tools still export animated WebP only through plugins rather than natively. GIF, by contrast, is understood by essentially everything ever made. If your workflow passes files through a lot of different apps, GIF's universal reach is the one genuine reason to keep using it.

Converting to a plain image format loses the motion

Only one conversion direction goes cleanly. Converting an animated WebP to a static PNG or JPG keeps a single frame and throws the rest away permanently, because neither PNG nor JPG has any concept of frames. There is no "export as PNG" that preserves motion. If you need to leave WebP but keep the animation, convert to GIF with a tool built for animated formats, not a plain single-image converter. Treat the animated WebP as the master and keep it.

Where Animated WebP Works and Where It Does Not

Animated WebP works across the modern web and most current apps, and stumbles mainly on old software and a few editors. Knowing where it plays cleanly is the difference between shipping it confidently and getting a broken box or a frozen frame.

On the web it is safe on every current browser, which is why sites that used to serve heavy GIFs now serve animated WebP for the same loops at a fraction of the weight. Some platforms lean on it directly: Discord serves its animated custom emoji as animated WebP behind the scenes, which is why a saved Discord emoji so often lands on your disk as a .webp file. Where it still fails is genuinely old browsers, some email clients that never adopted WebP at all, and a scattering of image viewers and editors that decode a static WebP but not an animated one. The safe pattern for anything mission-critical is the same as always: serve WebP as the primary source and keep a GIF or a static poster as the fallback for the long tail of software that has not caught up.