OpenCapture › Blog › Screenshots for bug reports
WorkflowThe screenshot that gets your bug fixed, and the one that gets it closed
Most bug reports contain a screenshot. Most screenshots in bug reports answer roughly one of the three questions a developer actually has — which is why the first reply is so often “can you send the full page?”
The short version. A useful bug screenshot answers three things at once: what you saw, where you were, and what state the page was in. A cropped viewport answers only the first. Capture the full page, leave the URL visible, mark the thing you mean, and blur anything that would stop the report being pasted into a public tracker.
Why the cropped screenshot keeps bouncing back
A tightly cropped image of the broken element feels like the considerate thing to send. It removes noise and points straight at the problem. It also removes every piece of context the person fixing it needs:
- Which page was it? Without the URL, someone has to guess the route.
- What width was the window? Half of all layout bugs are breakpoint bugs.
- What was above and below? A misaligned card is often caused by something two sections up.
- Was there an error banner elsewhere on the page? Cropped out, it never gets mentioned.
None of that is the reporter’s fault — the crop tool encourages it. But it turns a five-minute fix into a three-message round trip, and it is the single most common reason a ticket sits waiting for information instead of being worked on.
What a good bug screenshot contains
| Include | Why the developer needs it |
|---|---|
| The whole page, top to bottom | Shows the surrounding state, and any second error you did not notice |
| The URL | Identifies the exact route, query string and any feature flag in it |
| Window width | Distinguishes a real bug from a responsive breakpoint |
| A mark on the actual problem | Stops the reader hunting through a 6,000px image |
| Timestamp or build version | Tells them whether it is already fixed on main |
The last one is worth a word. “It is broken” against a build from three weeks ago is a different ticket from the same report against today’s deploy. If your app shows a version string in the footer, a full-page capture picks it up for free — which is one more argument against cropping.
A repeatable routine
- Reproduce the bug and leave the page exactly as it is. Do not scroll away, do not refresh.
- Capture the full page rather than the viewport, so the state above and below is preserved.
- Draw an arrow or a box around the thing you mean. One mark, not five.
- Blur anything private — customer names, email addresses, tokens in the URL. Cover them with a solid block, not a light blur.
- Attach it with the URL and the browser and window size written in the ticket body, not only in the image.
Write the URL as text in the ticket even though it is visible in the image. Text is searchable and clickable; an image of a URL is neither.
The console is a separate screenshot
If anything is failing at runtime, the browser console is usually more diagnostic than the page itself. Open DevTools, switch to Console, and capture it as a second image rather than trying to fit both into one. If you can, copy the error text out as text too — a stack trace that can be searched is worth several screenshots of the same stack trace.
The same applies to the Network tab when something did not load: the failing request, its status code and its response are the report.
Blurring is not optional
Bug reports get pasted into public repositories, forwarded to vendors, and attached to support threads that outlive the ticket. Anything on screen goes wherever the report goes. Before you attach:
- Session tokens and API keys in the URL or in a header panel.
- Customer names, addresses, phone numbers, order references.
- Internal hostnames, staging URLs and anything else you would not put in a blog post.
Cover them with a solid fill. A light blur over small text is often reversible, which is a surprise to most people the first time they hear it. There is a longer explanation of why in the piece on blurring.
When the bug is that the page is too long
Some bugs only show up at length: a footer that overlaps content after 4,000px, a virtualised list that repeats rows, a print stylesheet that breaks at page five. Those need the whole page in one image, and they are exactly the captures that hit the browser’s canvas ceiling. If your tool returns a blank or truncated image on a very long page, that is the limit rather than the bug — the mechanics are here.
How OpenCapture fits this
Full-page capture, arrow and box annotation, and solid-block blurring happen in the same pass before the file ever leaves your machine — the capture, the editing and the export all run locally in a Rust/WebAssembly core, so a screenshot of a staging environment is not uploaded to anyone on its way into the ticket. Very long pages are split or paginated automatically instead of silently truncating.
Common questions
Should I attach a full-page screenshot or just the broken part?
The full page. The surrounding state, the URL and often a second error you had not noticed are the things that let someone reproduce it without asking you a follow-up question.
How do I include the browser console in a bug report?
Capture it as a separate image, and paste the error text as text as well — a stack trace that can be searched and copied is worth more than a picture of one.
How do I hide customer data before attaching a screenshot?
Cover it with a solid block rather than a blur, and do it before the file is saved or shared. Bug reports get forwarded further than people expect.
Why did my screenshot of a very long page come out blank?
Browsers cap the size of a single canvas. Past that ceiling draw calls silently do nothing, so the export is blank or truncated. Tools that handle long pages split the output into segments or a multi-page PDF.