The reporter renders the current viewport in-browser — no screen-recording permission, no extension, no camera. The renderer is in a lazy chunk, so a page where nobody opens the reporter never downloads it.
Annotation tools
| Tool | Draws |
|---|---|
pen | Freehand. Five colours, three thicknesses. |
highlighter | Translucent freehand. |
rect · ellipse | Outlined shapes for circling a control. |
arrow | Points at the thing that broke. |
text | A label. Three sizes. |
redact | Draws a blur-kind shape — see below. |
pointer | Select, move and resize existing marks. |
The palette and sizes are identical across every TraceItX SDK, so a report looks the same whichever platform filed it.
Redaction is baked, not overlaid
A redact shape is rendered opaque into the image bytes before upload — not
stored as a region for a viewer to honour. The pixels underneath are gone by the
time the report leaves the browser.
That distinction matters. An overlay is a request; a bake is a guarantee. If a user blurs their bank balance, no receiver, no dashboard and no support engineer can recover it, because it was never uploaded.
The same applies to elements marked sensitive in code, which are masked before the screenshot is taken at all. See Sensitive content.
In the envelope
Two attachments can appear, and they are different things:
kind | What it is |
|---|---|
screenshot | The capture as taken. |
annotated-screenshot | The baked result, with drawings and redactions applied. |
Plus payload.annotations and payload.redactions, recording the vector shapes
the user drew. A dashboard can re-render annotations over the clean screenshot,
or offer a toggle — but only annotations. Redactions cannot be undone from the
annotated image, by design.
Size
The screenshot is usually most of an 84 KB report. The SDK bounds it itself: the
render is capped on its longest edge and encoded as WebP where the browser can,
and a capture that fails or overruns its time budget ships a placeholder image
with captureControl.degradedReason set rather than failing the report — a
report with no image but a full breadcrumb trail is far more useful than no
report.
What the renderer cannot see
The capture is a render of the DOM, not a screen grab, and three things fall outside it:
- Cross-origin images without CORS headers taint the canvas, and a tainted
canvas cannot be read. Those regions come back blank rather than failing the
capture. Serve images with
Access-Control-Allow-Originif they matter to your bug reports. - Cross-origin iframes are not readable at all — same-origin policy, not an SDK limit.
- Native browser UI — the URL bar, a
<select>dropdown that is open, a file picker, an extension popup — is not part of the document.
If a bug lives in one of those, the breadcrumb trail and the console state are what carry it.