Looping GIFs beat static screenshots for READMEs, docs, and bug reports. Convert your screen captures to crisp, text-readable GIFs in your browser.
Loading FFmpeg Core... (This may take a moment)
Files are processed locally and never uploaded.
Drop your screen recording into the uploader above — it never leaves your device.
Keep the width at 480px or higher so on-screen text stays readable; 10 FPS is enough for UI demos.
Convert, check the output size next to the download button, and embed the GIF in your docs or issue.
A screenshot shows a state; a GIF shows a behavior. For GitHub README demos, documentation, and bug reports, that difference is everything: a 5-second loop of the bug reproducing communicates more than three annotated screenshots and a paragraph. Readers see the clicks, the timing, the exact sequence — no video player required, no "click to play" friction.
GIFs also embed everywhere screenshots do: Markdown READMEs, GitHub issues, Stack Overflow answers, Notion docs, Jira tickets. Video embeds in those places are either unsupported or degrade into download links. A GIF just plays, inline, on every platform, forever.
Screen-recording GIFs live or die on text readability. The rule: prioritize width over frame rate. UI motion is slow — cursors, menus, form fills — so 8–10 FPS captures it perfectly, and the frames you save can be spent on pixels. 480px wide is the minimum for readable UI text; 640px is better for dense interfaces like IDEs and dashboards.
Record with this in mind too: zoom your browser or app to 125–150% before recording, and keep the capture region tight around the action. A full 4K desktop shrunk to a 480px GIF turns every menu label into mush; a focused 800px region at the same output width stays razor sharp.
The pattern that works: record the interaction once, slowly and deliberately — pause half a beat before each click so the loop reads clearly. Trim to the essential 3–8 seconds. Convert at 10 FPS / 480–640px wide. Check the size: GitHub renders images up to 10MB in Markdown, but a 2–4MB GIF loads faster and respects your readers' bandwidth.
Loop discipline matters. Cut the clip so the end flows back into the start — no awkward jump to an unrelated frame. A clean loop reads as one continuous demonstration; a sloppy loop reads as a mistake. Most screen recorders let you trim the tail; use it.
For bug reports, a GIF does something a video can't: it plays inline in the issue tracker without anyone pressing play. Maintainers triage dozens of issues; the one with a 4-second looping reproduction gets understood in seconds. Include the full interaction — the setup click, the trigger, the broken result — and keep the cursor visible.
One caution: screen recordings leak context. Before converting, check the frames for open tabs, API keys in environment variables, customer names in the background. Trim or re-record rather than shipping secrets inside your evidence. The conversion here is local, but the GIF you publish is public.
Mind the platform limits: GitHub Markdown images cap around 10MB, Stack Overflow lower. If your GIF is too big, shorten the clip first — halving duration halves the size with zero quality loss. Then reduce FPS to 8, then width to 480. Never sacrifice text readability to save a megabyte; a blurry demo GIF is worse than none.
And know when to graduate to video: tutorials over ~15 seconds, anything with narration, or demos where fine detail matters (sub-pixel rendering, color grading) belong in a hosted video with a thumbnail link. GIF is for the short, silent, loopable proof — used there, it's unbeatable.
8–10 FPS is the sweet spot for UI demos — cursors, clicks, and form fills all read clearly. Spend your size budget on width (480–640px) instead of frames; text readability matters far more than smoothness for documentation GIFs.
Three things: record at 125–150% UI zoom, capture a tight region around the action (not the full desktop), and convert at 480px wide or more. A focused 800px capture region at 480px output looks dramatically sharper than a 4K desktop shrunk to the same size.
GitHub renders images up to about 10MB in Markdown and issues, but aim for 2–4MB so pages load fast. If your GIF is over the limit, shorten the clip first (halving duration halves the size), then drop FPS to 8, then width to 480px.
Yes — inline GIFs are excellent in answers because they play without a click. Keep them short (under 8 seconds), focused on the exact step, and small enough to load quickly. A GIF that demonstrates the fix beats a code block alone for UI questions.