Why a GIF is the cheapest way to show motion in Figma
Figma is brilliant at static. It is not built to be a motion tool. You can fake a transition with Smart Animate inside a prototype, but that lives behind a Play button, in a separate window, and it breaks the second your trigger setup is slightly off. Meanwhile the person reviewing the file is looking at the canvas, where everything is a still image and your carefully designed spinner just sits there, not spinning.
A GIF in Figma, placed as an image fill, plays directly on the canvas. No prototype, no Play button, no presentation mode required. A reviewer scrolls past your frame and the loader is looping, the toast is sliding in, the toggle is flipping. That is the whole pitch: motion that shows up where people are already looking, in a format Figma renders natively, with zero setup on the viewer's end.
You feed the tool a screen recording or any video clip and it gives you the GIF. It does not record your screen for you, so capture the motion first (QuickTime on a Mac, the Xbox Game Bar on Windows, or export a frame range straight out of After Effects or Principle). Then turn that clip into a GIF with a screen recording to GIF converter and bring it into Figma.
How Figma actually handles an animated GIF
This is the part people get wrong, so it is worth being precise. Figma treats a GIF as an image, and an animated GIF animates in most places but not all of them:
- On the canvas: animated GIFs loop live, as long as you have not zoomed so far out that Figma pauses rendering to save memory. Zoom back in and it resumes.
- In Present / prototype mode: the GIF plays and loops there too, so it survives into a clickable prototype without any extra wiring.
- As a fill vs. as a placed image: either works. Drag the file onto a frame and it lands as a fill on a new rectangle, or paste it into an existing shape's fill. Both animate.
- In Dev Mode and PNG exports: a static GIF frame, not motion. Exporting a frame to PNG or handing it off in Dev Mode flattens it to one frame, which is expected. The motion is for viewing, not for the exported asset.
One catch worth knowing: Figma loops the GIF on its own clock, so two copies of the same loader on one page will drift out of sync over time. Usually nobody notices. If it bugs you, keep one instance per artboard.
The five-minute workflow
Say you have a recording of a button's loading-and-success animation and you want it living in your component spec. Here is the path from clip to canvas:
- Capture the motion. Record the interaction, or export a short clip from your motion tool. Grab a beat before and a beat after the moment, so you have room to trim cleanly.
- Convert it. Open the converter and drop the clip in. The whole thing runs in your browser tab, so a recording of an unreleased screen never leaves your machine.
- Crop to the component. Lock a ratio (1:1 for a button or icon, 4:3 or 9:16 for a full mobile flow) so the GIF drops into your frame at clean proportions instead of arriving as some odd dimension you have to fight.
- Trim to the loop. Use the frame-accurate timeline to set in and out points, nudging single frames with the arrow keys, so the motion starts and ends on a stable state and the loop does not visibly snap.
- Tune size and palette. Drop the frame rate to 10 to 15 fps and watch the live size estimate. UI motion does not need 30 fps, and your .fig file will thank you.
- Drag it into Figma. Drop the exported GIF straight onto your frame. It lands as a fill and starts looping. Position it inside your component documentation and you are done.
Keep your .fig file from getting fat
Every GIF you place is stored in the file, and GIFs are heavy compared to the PNGs and vectors Figma usually carries. Stack a dozen unoptimized loaders into one document and you will feel the editor get sticky, especially for teammates on slower machines or weaker connections. A few habits keep it tame:
- Crop before you scale. A button animation does not need the whole 1440px artboard around it. Crop tight to the component, then downscale, so you are not paying for dead pixels.
- 10 to 15 fps is plenty. Interface motion reads perfectly at low frame rates, and halving the fps roughly halves the file. Save 24 to 30 fps for anything with fast, fluid movement.
- Pull the color count down. Most UI is flat color, so 64 to 128 colors holds up fine and shaves real weight. Push toward 256 only when there is a gradient or a photo in frame. The small-file GIF approach is the same set of levers.
- Watch the estimate. The tool shows projected output size as you adjust, so you can land a loader under a few hundred KB before you ever leave the page.
If you need the crispest possible result for a hero animation on a portfolio frame, the trade-offs flip toward quality: hold the frame rate higher, keep the full 256-color palette, and let the live size estimate tell you what that costs.
Beyond mockups: FigJam, prototypes, and handoff
The same GIF earns its keep in more than one Figma surface:
- FigJam: drop a GIF onto a board to show a flow in motion during a workshop or a design crit. It loops right there next to your sticky notes, which beats a video link nobody clicks during a live session.
- Prototypes: because the GIF animates in Present mode, you can embed a true-to-life micro-interaction in a clickable prototype without rebuilding it with Smart Animate. Handy when the real animation is more complex than Figma's transitions can fake.
- Spec and handoff: place the loop next to your redlines so an engineer sees the intended timing and easing, not just start and end states. It answers the question before they have to ask it in a comment thread.
And because the conversion happens entirely in your browser tab without uploading, recordings of internal tools, unreleased flows, or anything under NDA stay on your machine. No vendor bucket, no signup, no watermark stamped across your design. For a wider walkthrough of placing GIFs in docs and decks, the Notion guide covers the same idea on a different canvas.