Two-frame animation
- Input
- A 64×48 GIF with red and green frames plus two different frame durations.
- Output
- A 404 byte WebP in RGB mode with one frame. The red first frame was visible, and no motion remained.
GIF → WebP returned a single-frame 404 byte WebP from our two-frame GIF, not an animated WebP.
From real runs
| Element | Result | What happens |
|---|---|---|
| Frame zero | Kept | The red first frame carried through to the WebP output and kept the 64×48 frame size. |
| Animation frames | Lost | The green second frame was not present because the source GIF was flattened before WebP encoding. |
| Loop and duration | Lost | The output opened as one WebP frame, so timing metadata was not useful for playback. |
| Palette source | Changed | GIF palette pixels were decoded to RGB before WebP compression. |
| File size | Changed | The 542 byte two-frame GIF became a 404 byte still WebP at quality 90. |
| Transparency | Changed | Transparency can be carried by WebP, but the tested opaque first frame produced an RGB WebP. |
The red first frame carried through to the WebP output and kept the 64×48 frame size.
The green second frame was not present because the source GIF was flattened before WebP encoding.
The output opened as one WebP frame, so timing metadata was not useful for playback.
GIF palette pixels were decoded to RGB before WebP compression.
The 542 byte two-frame GIF became a 404 byte still WebP at quality 90.
Transparency can be carried by WebP, but the tested opaque first frame produced an RGB WebP.
We converted our GIF sample (16 KB) with Image engine on 2026-10-20. It took 98 ms and produced a 18 KB WebP file, about the same size as the input. The engine raised 1 warning, listed below.
Input · sample.gif · 16 KB
1200 × 800 px, GIF87a
Output · sample.webp · 18 KB
1200 × 800 px, lossy VP8
For GIF screen captures, this pair sees only the first frame. Extract the relevant frame sequence or use OCR on a chosen frame when the content changes over time.
gif2webp
gif2webp in.gif -o out.webpgif2webp can preserve animation, unlike the still-image behavior observed in this image-ir path.
The HTTP API and the MCP server run the exact engine this page uses (Image engine); the response carries the same warnings the web converter shows. Check support first with GET /api/v1/pairs?from=gif&to=webp.
curl -X POST https://filetypeconverters.com/api/v1/convert \
-H "Authorization: Bearer $FTC_API_KEY" \
-F "file=@input.gif" -F "from=gif" -F "to=webp" \
-F 'options={"dpi":96}' \
--output output.webp| Key | Applies to | Type | Default |
|---|---|---|---|
| dpi | Reading GIF | number | 96 |
| width | Writing WebP | number | 0 |
| height | Writing WebP | number | 0 |
| fit | Writing WebP | contain · cover · fill | contain |
| quality | Writing WebP | number | 90 |
| background | Writing WebP | string | #ffffff |
| stripMetadata | Writing WebP | boolean | true |
No in the tested API path. The output opened as one WebP frame even though the input GIF had two frames.
Use it for a static thumbnail or poster frame. Use animated WebP tooling when playback is the goal.
No. Quality affects WebP compression for the extracted first frame, not which frame is chosen.