Linear is built for speed. A GIF is the only motion that keeps up.
Linear's pitch is that nothing waits: issues open instantly, the keyboard does everything. Then someone drops a two-minute recording into a bug and the reader is back to pressing play. Linear has shipped a video player since 2019, but a player is a request. A GIF is a fact on the page.
Drop one into a description and Linear treats it as an image, which in the web and desktop apps means it animates like any image: no controls, no poster frame, nothing asked of whoever opens it. Four seconds of the save button greying out and never coming back, looping right under the title. What works in Jira works here, minus Jira's attachments panel; the file lives in the text.
Three ways in, and where the file actually goes
Drag the .gif onto the description or a comment. Or stay on the keyboard: /file or /insert in the editor, Cmd Shift U to upload, and in a comment the paperclip or Cmd (Ctrl) Shift A. Wrong take? Uploads cancel mid-flight.
Hover for side handles and drag to size; several images in one description snap to each other's size, so a before and after line up. Click it for a lightbox, click again and it fills the window.
The part nobody considers: it's not on a public CDN. Linear keeps uploads in private storage at uploads.linear.app, and fetching one means being signed in (the API hands out signed links that expire; Linear's own example is 60 seconds). Your GIF of the admin panel is exactly as visible as the issue: the right answer, and useless in a public changelog, so re-upload where it's going.
Ten megabytes on Free, unlimited on paid, and why neither is the budget
As of this writing, Linear's pricing page lists a 10 MB cap per file upload on Free and none on paid; issues created by email carry their own, about 25 MB. Plans move; check first.
Unlimited is not a target; everyone who opens the issue pulls the whole file. Application chrome in a screen capture shrinks hard without visible loss, and the estimate updates with every dial:
- Trim to the failure. One beat before the click, one after the wrong thing. Split off the page load.
- 10 to 12 fps. A cursor, a menu, a spinner: none of it needs 60 a second.
- 64 colors. Flat UI and text survive it. Climb toward 128 only if a thumbnail starts banding.
- Crop to the component at native pixels. Downscaling a 1440p desktop turns error text into fuzz; cropping keeps it legible. Aim for 2 to 3 MB.
Four Linear situations where the GIF is the wrong attachment
- The evidence is a pull request or a Figma frame. Linear has link attachments for those: a GitHub card on the issue that shows the reviewers' actions and flips the issue to Done when the PR merges, or a Figma link that turns into a design preview. Paste the link. Don't screen-record a PR.
- The engineer needs to scrub. A race condition, where the point is which request landed first, wants a timeline, not a loop. Export the same edit as silent MP4 for Linear's player.
- The bug is intermittent. A loop proves it happened once, not how often. Put the count and conditions in text, or the fix gets tested against a ghost.
- Someone will read it on a phone. Linear doesn't document whether the mobile apps animate a GIF, as far as we can find. Open on a frame that names the screen, so a frozen first frame still works as a screenshot.
Two disks, no third party
A repro GIF has a short life: your machine, Linear's private storage, then people cleared to see the issue. An upload-first converter inserts an unlisted stop into that chain, with a retention policy nobody has read, holding footage of an unannounced feature.
This converter adds no stop. Your own browser decodes and re-encodes the recording, the finished .gif is written to your own disk, and the only upload is the one you make to Linear on purpose. Bug in a browser tab? Record a Tab grabs it through the share picker (desktop only, real time). Customer email in frame? A shape overlay covers it before export. The bug report guide has the capture craft for every tracker.