What should a screenshot in a bug report include?

The defect plus enough surrounding interface to locate it, captured at the viewport level rather than as a tight crop. Alongside the image, include the full URL with query string, viewport dimensions, browser and OS version, the logged-in role or account state, the app build version, and a timestamp with timezone so the screenshot can be joined to console and network logs from the same moment.

Is a screenshot enough evidence for a bug report?

No. A screenshot records output, not cause. It cannot show why a value is wrong, whether the underlying request was made at all, what errors the console threw, or whether the bug is intermittent. Pair it with console output and network requests from the same session; screenshot-only tickets are a recurring source of 'cannot reproduce' replies.

Should I annotate screenshots in bug reports?

Yes, but minimally. Use one arrow or box on the defect and write the expected result next to it, since only the reporter can state what should have happened. Annotate the wide shot rather than cropping to the annotation, and keep the unannotated original so interpretation never replaces evidence.

How do I redact sensitive data from a bug screenshot?

Draw opaque boxes over the data before attaching the image, never blur or reduce opacity, because both can be partially reversed. Redact before upload rather than after, since editing an attachment usually leaves the original in the ticket history. Where possible, reproduce with a test account holding synthetic data so there is nothing to redact.

Full-page or viewport screenshot for a bug report?

Viewport by default, because it shows what the user actually saw at their real window size. Add a full-page capture when the bug involves layout, overflow, scroll behaviour, or missing and duplicated sections. A region crop is a useful close-up but should never be the only image attached.

Screenshot Evidence in Bug Reports: What Makes It Useful

Screenshot evidence in bug reports is only useful when it carries three things beyond the picture itself: the exact region of the interface that is wrong, the state that produced it (URL, viewport size, browser, logged-in role), and a timestamp that lines up with the console and network logs from the same moment. A bare cropped image proves that something looked wrong on someone's screen once. A screenshot with that context attached lets a developer reproduce the bug without asking a single follow-up question — which is the only real measure of whether the evidence did its job.

What makes screenshot evidence in bug reports actually useful?

A screenshot answers exactly one question well: what did the user see? That is genuinely valuable, because rendering bugs, layout breakage, wrong copy, wrong currency, a misaligned modal, and a truncated label are all things that no stack trace will ever describe. Where screenshots fail is when they are treated as the whole report instead of one exhibit in it.

The difference between a screenshot that closes a ticket and one that starts an argument comes down to four properties:

It shows the defect and enough surroundings to locate it. A 200×80 crop of an error message tells a developer nothing about which page, which step, or which component rendered it.
It is unedited apart from annotation. Cropping out the parts that "aren't relevant" removes exactly the context the developer needs to find the component in the codebase.
It is anchored in time. If the screenshot was taken at 14:32:07, the console error at 14:32:07 is almost certainly the cause. Without a timestamp, the two pieces of evidence can't be joined.
It travels with its environment. The same page renders differently at 1440px and 375px, in Safari and in Chrome, and for an admin versus a trial user. A screenshot without that metadata is unfalsifiable.

Should you capture the region, the viewport, or the full page?

All three are legitimate, and each hides something the others show. The practical rule: capture the viewport by default, the full page when layout or scroll behaviour is involved, and a region only as an additional close-up, never as the only image.

Capture type	What it proves	What it hides	Best for
Region / crop	The precise defect, zoomed	Page identity, layout context, surrounding state	A close-up attached alongside a wider shot
Viewport	What the user saw, at their real window size	Content below the fold; scroll-dependent bugs	The default for most bug reports
Full page	Total layout, overflow, duplicated or missing sections	What was actually on screen; sticky elements often render oddly	Layout, spacing, and long-form content bugs
Screen recording	Sequence, timing, and interaction order	Nothing visual — but it is slow to review and hard to diff	Bugs that only appear mid-interaction

If you are choosing between a still and a video, our guide on screenshot vs. screen recording as bug evidence covers that trade-off in depth. For everything else, a viewport screenshot plus a full-page screenshot is cheaper to produce and far faster for a developer to scan than a 40-second clip.

What metadata has to travel with the screenshot?

This is where most bug reports quietly fail. The image is attached; the state that produced it is not. At minimum, ship these fields next to every screenshot:

Full URL, including query string and hash. Not "the checkout page" — the actual URL, because the parameters are often the reproduction steps.
Viewport dimensions and device pixel ratio. A responsive bug is a function of width; without the width, it isn't reproducible.
Browser and OS version. "Chrome" is not a version. Rendering and API behaviour differ across releases.
Authenticated role and account state. Admin, trial, expired, empty-state, or a specific tenant — many bugs only exist for one of them.
Timestamp with timezone. The join key between the screenshot, the console log, and the server-side trace.
App or build version. Tells the developer whether the bug is already fixed on main before anyone investigates.

Every one of these is available to the browser at capture time, which is why collecting them by hand is a waste of a reporter's attention. It should be automatic.

How should you annotate a screenshot without destroying the evidence?

Annotation is the one edit that adds information rather than removing it. Keep it disciplined:

Point, don't paint. One arrow or one box around the defect. Three colours of scribble make reviewers hunt for the actual claim.
Write the expectation on the image. "Should read £, shows $" next to the arrow removes an entire round-trip. The screenshot shows what happened; only you can say what should have happened.
Never crop to the annotation. Annotate the wide shot, then attach a crop separately if the detail is small.
Keep the original. If the annotated copy is the only copy, you have replaced evidence with interpretation.

The same discipline that makes a good annotation makes a good report body. The format we recommend is in how to write a bug report developers will actually act on.

What can screenshot evidence never prove?

A screenshot is a record of output, not of cause. It cannot show you:

Why the value is wrong — that lives in the network response or the application state, not in the pixels.
Whether the request even happened. A blank table looks identical whether the API 500'd, returned an empty array, or was never called.
Console errors thrown before, during, or after the frame you captured.
Intermittent behaviour. One image cannot distinguish "always broken" from "broken one time in twenty", and that distinction changes the priority.

This is why screenshot evidence belongs in a bundle, not alone. Pair it with the console output and the network requests from the same session, and the report stops being a claim and becomes a reproduction. Screenshot-only tickets are a recurring source of "cannot reproduce" replies, and the wider pattern — evidence gathered after the fact instead of at the moment of failure — is what our complete guide to AI QA is about.

How do you keep screenshot evidence safe to share?

Screenshots are the highest-risk attachment in a bug tracker, because they capture whatever happened to be on screen: a customer's real name and address, an email inbox, a session token in a URL bar, an API key in a devtools panel. Once that image is in a ticket, it is in the ticket's history, its notifications, and its exports.

Three habits keep this manageable. Redact before attaching, not after — editing an already-uploaded image rarely removes the original. Prefer test accounts with synthetic data for reproduction shots, so there is nothing to redact. And treat masking as destructive: draw opaque boxes, never blur or lower opacity, both of which can be partially reversed.

How do you make good screenshot evidence the default?

Every rule above is mechanical, which means asking humans to follow it is the wrong solution. Reporters are usually clients, testers, or teammates mid-task; they will send one cropped phone photo and a sentence, because that is what is easy.

The fix is to make the complete capture cheaper than the incomplete one. Klavity Snap does this by capturing on right-click: the screenshot, the URL, the viewport, the browser, the console errors, and the network requests from that moment are collected together and filed as one report, with annotation and redaction in the same step. The reporter's job shrinks to pointing at the problem and saying what they expected — the two things only they can supply.

The bottom line

Treat a screenshot as one exhibit with a chain of custody, not as the report. Capture the viewport rather than a crop, attach the URL, viewport size, browser, role, build, and timestamp, annotate with a single pointer and a stated expectation, redact destructively before upload, and always pair the image with console and network evidence from the same second. A report built that way is the difference between a developer opening a ticket and starting work, and a developer opening a ticket and starting a conversation.

Try Klavity free and let your next client site collect its own evidence — screenshot, console, and network, in one right-click.