Better Bug Reports With Screenshots and Short Videos
A practical template for bug reports developers can act on: what to capture, how to annotate it, and when a short screen recording beats a paragraph.

“It doesn’t work” is the start of a long conversation. A good bug report lets a developer see the problem, reproduce it and fix it without a single follow-up question. Here is a template that works, plus practical tips for screenshots and short recordings that make your reports impossible to misread.
Why visuals make bug reports faster
Words describe what you think happened. A screenshot shows the exact state of the page: the wrong number, the broken layout, the error message word for word. A short recording shows the steps that led there, in order, including the ones you didn’t think mattered. Together they remove most of the guesswork, and guesswork is what makes bugs slow to fix.
A bug report template that works
Copy this into your issue tracker and fill it in:
Title: [Where] [What goes wrong]
e.g. "Checkout: total ignores the discount code"
Steps to reproduce
1. Go to …
2. Click …
3. Enter …
Expected: what should happen
Actual: what happens instead
Environment
- Browser and version (from chrome://version)
- Operating system
- Account type or test user, if relevant
Evidence
- Annotated screenshot
- Short screen recording or GIF of the steps
- Console errors, if any
How often: every time / sometimes / once
Keep the title specific. “Checkout: total ignores the discount code” can be found, triaged and assigned in seconds. “Bug in checkout” cannot.
Screenshots developers can use
- Capture enough context. Include the surrounding area so the developer knows where on the page they are. A full-page capture is often best for layout problems, and an element capture for a single component.
- Number the steps. FrameShot’s step markers count themselves, so marker 1, 2 and 3 can match the steps in your report.
- Point, don’t describe. An arrow at the problem and a box around the wrong value beat a paragraph of explanation.
- Add the expectation. A short text note such as “Expected: $25.00” right next to the wrong number makes the bug obvious.
- Hide customer data. Use a solid redaction box for anything personal before you attach the image.

When to record instead
Record a short video when the bug is about timing or sequence: something flickers, a menu closes too early, an animation stutters, or the problem only appears after several steps. Recordings are also the best way to report bugs that happen only sometimes, because you can capture the one time it does.
- Start one step early, so the starting state is visible.
- Keep it short, ideally under a minute. Pause the recording while you set up the next step.
- Narrate with your microphone: “Now I click Pay, and the total is still the old amount.”
- Share just the tab to keep notifications and other apps out of the video.
- Attach a GIF when your tracker doesn’t play videos inline. FrameShot’s Export GIF turns the key moment into a small looping clip.
Add the technical details
A few extra details save a developer a lot of time:
- Console errors. Press F12, open the Console tab and copy any red errors as text. Text can be searched; a picture of an error can’t. DevTools sits outside the web page, so page capture tools don’t include it.
- Failed requests. In the Network tab, a request shown in red with a status like 404 or 500 often points straight at the cause.
- Exact versions. Open
chrome://versionand copy the first line. - The page address. Paste the full URL, minus any private tokens.
Before you hit submit
- Can someone who has never seen the bug follow the steps?
- Does the title say where and what?
- Is the expected result written down, not just the actual one?
- Is the evidence attached, annotated and free of personal data?
- Did you include the browser, the operating system and how often it happens?
Five yeses and your report is ready. The developer reading it will thank you, and the bug will be fixed sooner.


