Screenshot annotation
Screenshot annotation is the step where a reporter draws on a captured image of the page, with an arrow, box, or highlight, to mark exactly what they are talking about.
Technically it is two operations. Capture renders the page in the browser, either by drawing the DOM to a canvas or by using the browser capture API. Markup is a small editor on top of that image: arrow, rectangle, freehand pen, and usually a blur tool for anything on screen that should not travel with the report.
The markup is what carries the meaning. A raw screenshot of a long documentation page still leaves the recipient scanning for the problem, and a long page screenshotted at full height can be worse than no image at all. One arrow pointing at one code sample turns a two-message exchange into zero.
Two practical constraints decide whether this works in production. Redaction matters when readers are signed in and their screen holds real data, so the editor needs a blur tool and the capture must be triggered by the user rather than collected in the background. And the image should be stored alongside the page URL, never instead of it, because a URL is searchable and an image is not.
Frequently asked questions
How is a screenshot different from an annotated screenshot?
A screenshot shows the page. An annotation shows the point. Without markup the recipient still has to find the problem inside the image, which is the work the reporter was best placed to do.
Can annotated screenshots capture sensitive data?
Yes, and that is the main risk in the feature. The annotation step should include a blur tool, the capture should always be user-initiated, and the retention policy for images should match the one for the rest of the feedback record.
Does screenshot capture work on every page?
Mostly, with known exceptions. DOM-based capture can miss cross-origin iframes, canvas and WebGL content, and some custom fonts. Test the pages that matter before rolling a widget out site-wide.