Someone sends a screenshot of an error. It is a full-desktop capture at 3840 pixels wide, the error is a small grey box in the corner, and the top of the frame shows an email notification containing a customer name.
Both problems are the same problem: the capture included everything, and nothing was done to it afterwards.
Crop first, redact second
The quickest way to remove something sensitive is not to include it.
Cropping is lossless and immediate. A full-screen capture cropped to the dialog and its surrounding context removes the notification banner, the bookmark bar, the taskbar clock and the other open tabs in one action, without any decision about what to black out.
What to keep: the error itself, the URL bar if it is a web page, and enough surrounding interface for someone to find the same screen. What to drop: everything else.
Redaction in an image is real
This is one place where the intuitive action is actually correct, and it is worth being explicit because the opposite is true elsewhere.
Drawing an opaque filled rectangle over text in an image overwrites those pixels. The original values are gone from the exported file. There is no layer underneath and nothing to recover.
That is the reverse of the situation in a document, where a black rectangle is not redaction because the text remains in the content stream beneath the drawing.
Two conditions on that, though.
And export a new file rather than saving over the original, because the flattening is what makes it permanent and you may want the unredacted version later.
Annotation that helps
An arrow pointing at the problem beats a paragraph describing where to look. Drawing on the image covers the useful set: a box around the affected region, an arrow to the specific control, and a highlight on the value that is wrong.
The practical guidance is short. Use a colour that does not appear in the interface, which usually means red or magenta over a typical grey application. Keep the stroke thick enough to survive being viewed at half size in a chat window. And annotate sparingly, because five arrows communicate less than one.
If the report needs a diagram rather than a marked-up capture, the drawing board is the same idea with no image underneath.
What a good bug screenshot contains
The most common failure is not a leak, it is a screenshot that does not contain enough to act on.
- The error message in full, not truncated by the crop.
- The URL, if it is a web page. This is the single most useful element and the one most often cropped out.
- The timestamp, which is why the system clock is sometimes worth keeping.
- Enough interface to identify which screen this is.
For anything involving a web page, a browser console screenshot is worth more than the visual one, because that is where the actual error text lives. The visual capture says something is wrong; the console says what.
Before you send it
Two final steps that take seconds.
Strip the metadata. Screenshots carry less than photographs, and they do carry the capture timestamp and often the device and software. A photo of a screen taken with a phone carries GPS coordinates, which is a real disclosure when the screen is at your home.
Compress it. A 3840px PNG of a dialog is several megabytes for no benefit. PNG is the right format here, since a screenshot is text and flat colour, which is exactly the content JPEG handles badly. Reducing the dimensions to what is readable is usually enough.
All of it runs in this browser tab, which is the relevant property when the screenshot is of an internal admin panel with real customer records on it, which is what support screenshots very often are.