- Tutorial
- Studio
- Screen recording
How to make a GIF from a screen recording on a Mac
A good UI GIF is a trimmed, reframed, silent loop under ten seconds — made from a screen recording, not a camera pointed at one. The workflow, the size math, and when MP4 wins instead.
The GIF is the postage stamp of software marketing: tiny, silent, everywhere — READMEs, pull requests, chat threads, landing pages. Making a good one from a screen recording is mostly subtraction: less time, less frame, less color. Here’s the workflow, and the size math that decides whether you ship a GIF at all.
Start from a recording, not a GIF recorder
Capture first as a normal screen recording — the highest‑quality source you can get — and make the GIF from it. GIF recorders that capture directly lock you into whatever they grabbed: no reframe, no second trim, no re‑export when the first loop comes out too long. A recording is the master; the GIF is one export of it. (Recording a demo cleanly matters double here, because every flaw survives the loop.)
Trim to the smallest loop that lands
A UI GIF should show one motion: the menu opening, the card flipping, the drag completing. Under ten seconds, ideally under six — the loop is what does the work, so the viewer sees it twice while deciding to care. Cut the lead‑in (the part where you find the menu) and the dead air after the action completes. If the motion needs more than one beat to read, that’s two GIFs, not one long one.
Reframe before you export
The full window is rarely the story. Crop to the region where the motion happens — a modal, a sidebar, one panel — because fewer pixels means a smaller file and a clearer point at the same time. Vertical slice for a chat thread, square for a card, whatever the destination wants: reframe after recording, from the master, and keep the same crop every time you re‑export so the series looks like one product.
The size math
GIF is an ancient format doing modern work: 256 colors, no real video compression, and it pays for every frame. Three levers keep the file sane:
- Frame rate over smoothness. UI motion reads fine at 10–15 fps; film‑style 30+ fps doubles the weight for no visible gain on a cursor drag.
- Fewer colors is invisible on flat UI. A palette built from the clip itself (rather than the full 256) is usually undetectable and meaningfully lighter.
- The destination caps you anyway. GitHub’s attachment limit is 10 MB; chat apps’ upload caps are tighter. If the export misses the cap, the fix is shorter, smaller, slower — in that order.
GIF keeps one superpower worth remembering: it autoplays and loops everywhere, no player chrome, no click‑to‑play. That’s why READMEs and pull requests still prefer it.
When MP4 wins instead
Silence and autoplay are the GIF’s whole pitch; everything else favors MP4 — smaller at the same quality, real audio when the demo needs its sound, seekable in a player. The rule of thumb: GIF for the looping silent moment, MP4 for anything longer than ten seconds or anything with narration.
The one‑sitting route
By hand this is: record, open an editor, trim, crop, palette‑encode, check the size, repeat — an evening for a first‑timer. Snapbak collapses it: record as usual, pick GIF mode, trim by transcript, reframe, and the palette encoding is handled — exports sized to fit under chat and GitHub limits, with a poster still for people who browse with motion off. The honest disclosure: I make Snapbak, and the GIF pipeline is one of its reasons to exist — weight that accordingly.
Snapbak is free for the first 100 users: download it, record your next “here, watch this” moment once, and ship it as both GIF and MP4 from the same take.