Guide
How to write a bug report with useful screenshots
A useful bug report screenshot shows the problem, preserves enough page context, hides sensitive details, and pairs with clear reproduction steps.
Quick answer
A useful bug report screenshot shows the actual problem, keeps enough page context to reproduce it, hides anything sensitive, and pairs with clear reproduction steps. The screenshot supports the words; it does not replace them.
Captorify helps with full-page capture, annotations, redaction (Pro), and PDF export, but there is no built-in bug-tracker integration: you attach the file or a share link to your tool yourself.
Report fields
A complete report gives the reader everything they need to reproduce and prioritize the issue. Keep it short but specific.
- Summary: one line describing the problem
- Environment: browser, version, OS, and account or role
- Steps to reproduce: numbered, from a known starting point
- Expected result and actual result
- Screenshot or recording showing the problem
- Severity and how often it happens
Screenshot requirements
Capture enough of the page that the reader can locate the problem, not just a cropped detail with no context. A full-page capture is useful when the issue depends on layout or content far down the page.
If a console error or network failure is part of the bug, capture that too. Captorify full-page capture auto-hides sticky headers so they do not repeat down a long capture.
Annotation example
Use the editor to add a box or arrow pointing to the exact element that is wrong, and a short text note if it is not obvious. Annotations save the reader from hunting for what you saw.
Keep annotations minimal: one clear marker beats a cluttered image.
Redaction
Bug screenshots often capture real account data, customer details, or internal URLs. Black out anything sensitive before attaching the image, using blackout rather than blur so it cannot be recovered (Pro).
A bug report still reproduces fine with a redacted name or token; it does not need the real values.
Source context
When the page and time matter, export the capture as a PDF with the optional URL and timestamp overlay (a Pro opt-in) so the report records where and when it happened. This is added context, not tamper-proof proof.
For most bugs a clean annotated image plus written steps is enough.
Completed template
Put it together as a repeatable template so every report has the same shape:
- Summary: [one line]
- Environment: [browser/version, OS, role]
- Steps: 1) ... 2) ... 3) ...
- Expected: [what was supposed to happen]
- Actual: [what happened] + annotated, redacted screenshot
- Severity / frequency: [value]