Better bug reports: what to screenshot, and what to hide first

OpenCapture — Thu, 03 Sep 2026 06:17:42 +0000

Most bug reports contain a screenshot. Most of those screenshots are either not enough to reproduce the problem, or contain something that should not have left the building.

Both are fixable in about thirty seconds each.

Capture more than the error

The instinct is to screenshot the error message. The error message is usually the least informative part of the page.

What the person fixing it needs is context: the URL, the state of the form, what else was on screen, and — often decisive — the browser console. An error alone tells them what broke. The surrounding page tells them why.

A full-page capture costs nothing extra and removes an entire round trip of "can you send the whole page?"

Include the things you are tempted to crop

The URL bar. Query parameters and path segments are frequently the difference between reproducing a bug and not.

Timestamps. If the page shows one, it lets someone match your report against server logs.

The console. Open DevTools before capturing. A stack trace in the image saves a day.

Your viewport size. Many layout bugs only exist at certain widths. Some tools stamp dimensions on the capture; if not, mention it.

Then hide the things you are tempted to leave

Bug reports travel further than the person writing them expects. They get pasted into group chats, forwarded to vendors, attached to public issue trackers.

Before sending, redact:

Customer names and email addresses visible in tables or headers
Account and order identifiers that map to a real person
API keys or tokens visible in a logged request or a URL
Internal hostnames that reveal infrastructure
Anything in an adjacent browser tab — tab titles are readable

Redaction has a failure mode

Two operations are both called blur, and only one of them removes information.

Some tools draw a blurred overlay while the original pixels remain in the underlying data. Depending on the export, that can sometimes be recovered. Others resample the region and discard the source, which cannot be undone.

Test yours once: blur a line of text, export, open the export, and push contrast and sharpness hard. If characters start resolving, use a solid box instead of blur for anything that matters.

Solid boxes are ugly and completely reliable. For a token, take the ugly option.

A checklist worth pinning

Full page, not just the error
Console open if it is a JavaScript bug
URL visible
Redact names, emails, IDs, tokens, internal hostnames
Check no other tab is readable
Note the browser and viewport width

Six items, about a minute, and it removes most of the back-and-forth that makes bug reports slow.

Disclosure

I work on OpenCapture, an open-source screenshot extension built around this workflow — full page capture, annotation, and a destructive mosaic blur rather than a cosmetic one. But the checklist above works with whatever you already have, including the capture tool already built into your browser.