The most expensive field on the ticket
Every bug tracker has the same failure mode and Jira has a status for it. A ticket gets filed, a developer can't reproduce it, the ticket flips back to Needs Info, the reporter adds detail from memory a day later, and the loop runs again. Two engineers spend a week passing a text field back and forth about something that took nine seconds to occur.
What breaks down is translation. You saw a sequence: hover, click, the dropdown opening a beat late and landing behind the modal. You then compressed that into numbered sentences, and the developer expanded your sentences back into a sequence, guessing at everything you didn't think to mention. The browser, the window width, the fact that you'd scrolled first.
An embedded loop removes the compression step. The developer sees the actual sequence, at the actual speed, in your actual window, and the guessing stops. Every ambiguity you would have had to anticipate is simply visible.
Your admin picked a number and you should know it
Jira caps attachment size, and the ceiling is set by whoever administers your instance. Jira Cloud commonly defaults to around 10 MB per file, and admins can raise or lower it, so the practical answer is to check your own site rather than trust a number from a blog post.
Assume something in that range and a GIF gets comfortable fast, because ten megabytes is a lot of GIF if you spend it deliberately:
- Trim before anything else. Four seconds versus twelve is the difference no compression setting can make up. Start one beat before the interaction and stop the instant the bug is visible.
- Cut the frame rate. Interface footage reads correctly at 10 to 12 fps. A 60 fps screen recording is carrying five times the frames it needs to prove a dropdown misplaced itself.
- Thin the palette. Application chrome is mostly flat fills, so 64 colors usually looks untouched where a photograph would fall apart.
- Split out the dead air. If the page load at the front is eight boring seconds, cut the clip at the playhead and delete that half instead of shipping it.
The size estimate updates while you change those, so you land under the limit before encoding rather than after a failed upload.
Crop to the component, not the monitor
This is the mistake that ruins otherwise good bug GIFs, and it is worth its own section. A full-screen capture from a 1440p display is about 2,560 pixels wide. Jira's issue view renders it a few hundred pixels wide, and to hit an attachment limit you probably downscaled it further. Your 12-pixel error message is now four pixels tall and legible to nobody.
Crop to the region where the bug happens instead, then keep that region close to its native pixel size. A 700-pixel-wide crop of the actual form control, at full resolution, is smaller as a file and infinitely more readable than the whole desktop squeezed down to the same byte count. Downscaling is what destroys text; cropping is what saves it. The bug report guide covers the rest of the settings for crisp UI capture.
If the bug is in a web app, Record a Tab captures the staging tab directly through the browser's own share picker, so you can grab just that tab without a separate recorder. Desktop browsers only, and it records in real time. There are also shape overlays if a customer name or an email address wandered into frame and needs a censor bar over it before the ticket goes anywhere.
What a GIF cannot carry into a ticket
It is not the universal answer and treating it as one produces worse tickets, not better ones. Skip the GIF when:
- The reproduction runs long. Past roughly fifteen seconds you are fighting the format. Attach a video or link the recording and use the GIF for the five seconds that matter.
- You were narrating. GIF has no audio track, so any explanation you spoke out loud is gone. Type it in the description or add a caption to the frame.
- The evidence is text. A stack trace, a request payload, a console error: paste it in a code block. Nobody can copy an error message out of a loop.
- Timing is the bug. If the complaint is that something took four seconds, the loop shows sluggishness but not a measurement. Put the number in the description.
The strongest ticket usually pairs them: a short loop showing what happened, plus the log line proving why.
Staging builds should not go up to a converter
A bug GIF is, almost by definition, a recording of software that is not finished. Unreleased interface, a feature behind a flag, sometimes a real customer's account open in the admin panel. Uploading that to a free web converter means an unannounced product decision now exists as a file on a server belonging to a company nobody on your team has evaluated.
This one converts inside the tab. The recording is read from your disk, encoded by your own processor, and written back to Downloads, with no upload step anywhere in the sequence. Kill the network once the page is open and the conversion still completes, which settles the question faster than any policy document could. That property is why it also works for the README demos and product demos your team ships publicly later.
One more argument for putting the loop in Jira rather than the Slack thread: the ticket is the record. Slack messages age out of retention and threads get archived, but the attachment on the issue is still there when someone reopens it in eighteen months asking whether this ever got fixed.