Video to GIF, in your browser
No upload, no queue, no watermark on your pixels. The conversion runs on your machine, which is rather our whole philosophy. Perfect for demo GIFs in READMEs, pull requests and docs.
Long videos, 4K, or batches? The CoAnimator desktop app renders unlimited, full-quality exports locally.
how it works
How to convert a video to a GIF
Drop an MP4, WebM or MOV into the converter, choose the segment, size and frame rate, and download the GIF. The conversion runs in your browser with WebAssembly FFmpeg. Nothing uploads, nothing to sign up for, no watermark.
- Drop your video into the converter — mp4, webm and mov all work.
- Trim to the moment you need. GIFs are best under ~10 seconds.
- Pick width and frame rate — 480–640 px at 8–12 fps is the README sweet spot.
- Convert and download the palette-optimized GIF.
settings
What to set for where the GIF is going
Three settings decide both quality and file size: width, frame rate and duration. Every destination has a different tolerance for the resulting file, and the limit that bites first is almost always size, not resolution. Start from the numbers below and only push higher if the destination accepts it.
GitHub README or pull request
GitHub caps images at 10 MB and renders content columns around 850 px wide. 600 px at 10 fps, under 10 seconds, keeps you comfortably inside both and stays sharp on a retina screen.
Documentation sites
Docs pages are read, not skimmed, so favour legibility over motion: 640–720 px at 8 fps. A lower frame rate on UI footage is barely noticeable because most pixels hold still between frames.
Slack and chat tools
Slack plays GIFs inline and starts them automatically, so short loops work best. 480 px at 10 fps under 5 seconds keeps the file small enough to post without a wait on slow connections.
The most constrained target. Keep under 1 MB, use 480 px and 6–8 fps, and make the first frame carry the message. Several email clients show only the first frame and never animate.
Issue trackers and wikis
Linear, Jira, Notion and Confluence all render GIFs inline in a comment, which makes them the fastest way to show a bug reproducing. 600 px at 10 fps is plenty; the reader is looking for one specific behaviour, not production polish.
X and LinkedIn
Both accept GIF uploads and both transcode to video on their side, so the file you upload is not the file people watch. Upload MP4 directly where you can, keeping the colour and skipping a lossy round trip. If you must use GIF, stay under 15 MB.
format choice
GIF, MP4 or WebP?
GIF survives because it plays anywhere without a video player, autoplays without permission, and needs no controls. It pays for that with size. The format stores each frame as a separate image limited to a 256-colour palette, with no compression across frames, so a gradient or a camera pan produces a far larger file than the same footage as video, with colour banding on top.
MP4 compresses by describing what changed between frames, which is why the same clip can be an order of magnitude smaller with better colour. Use it wherever a video tag will play, from your own site to landing pages and social posts. WebP sits between them, animating like GIF at roughly a third the size with full colour, and is now supported by every current browser. It still fails in many README renderers and email clients, which is exactly where people reach for a GIF in the first place. Convert to GIF when the destination will not play video, and use MP4 when it will.
file size
Why GIFs get large, and the three levers that fix it
File size scales with width times height times frame count, so each lever is multiplicative rather than additive. Halving the width removes roughly three quarters of the pixels, because height falls with it. Dropping 24 fps to 12 halves the frames. Trimming a 30-second clip to 8 seconds removes nearly three quarters again. At 640 px and 12 fps, a 30-second GIF already weighs around 16 MB; the same footage at 480 px, 10 fps and 8 seconds lands in the low hundreds of kilobytes.
Content matters as much as settings. Screen recordings compress well because most of the frame is static and flat-coloured. Anything with film grain, a moving camera, or a gradient background defeats the palette and inflates every frame. If a recording has a busy desktop wallpaper behind it, re-recording against a plain background will do more for file size than any converter setting.
file size
How big will the GIF be?
Size scales with width × height × frame count, so the three settings multiply rather than add. Our measured baseline is a 30-second clip at 640 px and 12 fps, which lands around 16 MB. Everything below is that baseline scaled by the arithmetic, so treat it as an estimate for typical screen-recording footage. Flat UI compresses better than the table suggests, and anything with grain, gradients or a moving camera comes out larger.
| Settings | 5 seconds | 10 seconds |
|---|---|---|
| 480 px, 8 fps | ~0.6 MB | ~1.2 MB |
| 480 px, 12 fps | ~0.9 MB | ~1.8 MB |
| 640 px, 10 fps | ~2.2 MB | ~4.4 MB |
| 640 px, 12 fps | ~2.7 MB | ~5.3 MB |
| 800 px, 12 fps | ~4.2 MB | ~8.3 MB |
| 1024 px, 15 fps | ~8.5 MB | ~17 MB |
Read it as a budget rather than a promise. If a destination caps uploads at 10 MB, the last row is already out of reach at ten seconds, and the fix is always the same order of operations: shorten first, drop the frame rate second, reduce the width last. Width is the lever people reach for first and it costs the most legibility, because text in a screen recording stops being readable well before the file stops being large.
troubleshooting
Five things that go wrong with GIFs
Almost every complaint about a GIF traces back to one constraint. The format was designed in 1987 and allows 256 colours per frame. These are the symptoms that causes, and what fixes each one.
Banding in gradients
A smooth background turns into visible stripes because the palette cannot represent the in-between shades. Dithering hides it by scattering pixels between two colours, at the cost of a larger file. The cheaper fix is to record against a flat background.
Colours look washed out
Brand colours shift because the encoder picks one 256-colour palette for the whole animation and yours did not make the cut. Shortening the clip narrows the range of colours competing for palette slots, which usually restores the ones that matter.
The file is enormous
Usually motion, not settings. A GIF stores whole frames, so anything that changes most pixels (a camera pan, a full-screen transition, film grain) defeats the compression. Cutting the pan out does more than any width or frame-rate change.
Text is unreadable
Small UI text falls apart below about 600 px because there are not enough pixels left for the letterforms. Zoom the recording into the region that matters instead of shrinking the whole screen. A cropped 600 px GIF beats a full-desktop 1200 px one at the same file size.
It loops when it should not
GIFs loop forever by default and there is no pause control, so a demo that ends mid-action reads as broken. End on the finished state and hold it for a beat, so the loop point looks deliberate.
The first frame is wrong
Several email clients and some feed readers show only frame one. If your clip opens on an empty state or a loading spinner, that is the still image most people see. Trim so the first frame already shows the thing you are demonstrating.
the format
Why GIF still exists
GIF is worse than every modern format on every technical measure: 256 colours against millions, no inter-frame compression, no sound, no hardware decoding. It survives because of a single property none of the better formats reliably have. It is an image. Anywhere that accepts an image accepts a GIF, and it plays automatically, silently, with no player, no controls and no permission prompt.
That matters most in the places developers publish. A README on GitHub renders images and will not run a video element. A comment on an issue tracker, a Slack message, a docs page built from Markdown, an email — all of them display an image without being asked and none of them can be relied on to play a video. The moment a video tag is available, MP4 wins on every axis: roughly an order of magnitude smaller at the same quality, full colour, and sound if you want it.
WebP and AVIF both animate, both keep full colour, and both produce far smaller files. Support in browsers is no longer the problem. The gap is everywhere else: README renderers, email clients, chat previews and CMS uploaders still treat them inconsistently, and those are the destinations that drove you to a GIF in the first place. Use GIF where the destination cannot play video, use MP4 where it can, and revisit WebP when the tools around your publishing surface catch up.
Two accessibility habits are worth keeping, because a GIF gives the viewer no controls at all. Write alt text that describes what happens, not what the file is. “Deploy command running and finishing in eight seconds” tells a screen reader user something; “demo GIF” tells them nothing. And avoid anything that flashes more than three times a second: a rapid strobe or a hard cut between very light and very dark frames can trigger photosensitive seizures, and the WCAG guidelines set that limit for exactly that reason. An autoplaying, unstoppable, looping image is the worst possible place to put one, since nobody can pause it. Slowing the transition down or holding the end state fixes both problems at once, and usually reads better anyway.
CoAnimator is the full studio, driven by your AI agent.
- Real-footage effects
- Motion graphics
- 3D scenes
- Voiceover
- Unlimited local renders
FAQ
How do I convert a video to a GIF?
Drop your clip into the converter above, pick the segment and size, and download the GIF — it runs in your browser, no account needed. For anything longer than a few seconds, trim first: GIFs balloon in file size quickly compared to video.
Is this video-to-GIF converter free?
Yes — it’s a free tool from the CoAnimator team, with no watermark on the output and no upload: the converter runs entirely in your browser with WebAssembly FFmpeg, so the file never leaves your machine.
When should I use a GIF instead of MP4?
Use GIF where video embeds won’t autoplay — README files, docs, some email clients, and chat tools. Use MP4 everywhere else: it’s dramatically smaller at the same quality and supports sound. A good rule: GIFs under ~10 seconds, MP4 for anything longer.
Why is my GIF so large?
GIF is a 1987-era format storing every frame as an indexed image, so size grows fast with dimensions, frame rate, and duration — at 640 px and 12 fps, a 30-second GIF already weighs ~16 MB. Reduce width to 480–640 px, cap the frame rate at 8–12 fps, and shorten the clip; those three levers matter far more than “compression” settings.
What formats work, and is there a length limit?
Anything your browser and FFmpeg can read: mp4, webm and mov cover almost everything. Compute isn’t the limit — a 90-second 1080p clip converts in about 24 seconds right in the browser; file size is the real constraint, so keep GIFs under ~15 seconds for embeds.
How do I make an animated demo GIF from scratch?
If you’re producing the animation itself — not just converting footage — that’s what CoAnimator is for: an AI agent builds the demo animation as an editable project and renders it locally, then this tool converts the MP4 to GIF for your README or docs. No credits, no watermark.
How do I reduce GIF file size?
Shorten the clip first, drop the frame rate second, reduce the width last — in that order. Duration and frame rate both cut the frame count directly, while width costs you legibility faster than it costs bytes. Cutting a camera pan or a full-screen transition often saves more than any setting, because a GIF stores whole frames and anything that changes most pixels defeats the compression.
What frame rate should a GIF be?
8 to 12 fps for screen recordings, 12 to 15 for anything with real motion. UI footage holds still between frames, so a lower rate is barely visible while halving the frame count and roughly halving the file. Below about 8 fps motion starts to read as stuttering rather than as a deliberate style.