I Got Tired of Explaining UI Bugs With Screenshots

A lot of UI bug reports start with a screenshot and one sentence:

The dropdown is broken on mobile.

Then someone asks:

What did you click before that?

Then someone else asks:

Can you send a recording?

And now the bug report has become a conversation about the bug report.

The screenshot shows the result, but not the interaction that caused it. A screen recording solves that part, but then you have a video file that is too large to casually paste into an issue or a chat. So the usual next step is to find a GIF converter, upload the video, trim it, add a note somewhere, export the GIF, then compress it because the GIF is now too large.

I got tired of doing that.

Not because any one of those tools is difficult to use. The annoying part is moving the same file through several tools just to explain one small UI problem.

So I built GIF Master, a browser-only workflow for turning a recording into a small annotated GIF.

The idea is simple, put all the steps into single window, no more file downloads and uploads:

Record the issue.
Then
Mark the issue.
Then
Make it small enough to share.

The kind of bug this is for

Take a common example: a dropdown menu covers the submit button on a narrow screen.

A ticket that says “dropdown is broken on mobile” is technically true, but it leaves a lot open:

• Which page?
• Which viewport?
• Does it happen before or after opening another panel?
• Is the button hidden, moved, or just unclickable?
• What should the expected layout look like?

A short GIF can answer all of that without turning the issue into a wall of text.

The useful version of that report is usually only a few seconds long:

1. Open the settings panel.
2. Switch to a narrow viewport.
3. Open the dropdown.
4. Show the menu covering the button.

Then add a red rectangle around the collision, an arrow pointing to the dropdown, and one sentence:

Expected: the menu should stay above the form.

That is enough. The person reading the issue knows what happened, where to look, and what the expected behavior is.

I did not want another “all-in-one dashboard”

The workflow I wanted was deliberately boring.

Start with a screen recording. Keep only the useful part. Add text, arrows, rectangles, emoji, or a small image when they help explain the issue. Export a GIF. Compress it. Download it.

No new browser window. No sending the recording to a server first. No exporting a video just so another tool can ask you to upload that same video again.

The tools are connected because the task is connected:

• A recording gives the bug report context.
• A short GIF makes the context easy to consume.
• An annotation removes ambiguity.
• Compression makes the result practical to paste into GitHub, Slack, Linear, Notion, or a pull request.

That last part matters more than it sounds.

A GIF that is clear but too large to send is still inconvenient. A GIF that is tiny but unreadable is not useful either. The goal is to reduce the size enough for quick sharing while keeping the UI details and annotations legible.

Why I kept the files in the browser

Bug recordings can be awkward.

They may contain a staging environment, an internal admin page, customer data, unfinished features, or an account that should not be uploaded to a random service.

GIF Master processes the recording, editing, GIF generation, and compression in the browser. The file stays on the device unless you decide to export and share it.

That does not make every recording safe by default. You still need to be careful about what is visible on screen. But it removes one unnecessary step from the workflow: uploading a bug recording before you have even decided where it should go.

A GIF is not the whole bug report

I still want the usual details in a good issue:

• Steps to reproduce
• Expected behavior
• Actual behavior
• Browser, device, or viewport details
• Console errors when relevant

The GIF is there to make the visual part obvious.

It is especially useful for things that are annoying to describe precisely: a layout shift, a hover state that disappears too early, a modal that closes unexpectedly, a button that becomes covered by another layer, or an animation that ends in the wrong