Annotate Screenshots for Clear Bug Reports

The fictional Alder Archive catalog provides a practical example: a selection counter appears inconsistent with the visible result list. The editor annotates a supplied screenshot; it does not capture or inspect an application.

Separate the visible symptom from the suspected cause

A useful screenshot annotation directs attention to something another person can actually see. It should not turn a suspicion about software into an established diagnosis. A counter showing three selected items beside one visible highlighted row is an observation. “The filter function lost two records” is a possible explanation that needs more evidence. Write the observation first, then identify the part of the screen that supports it. The screenshot can preserve the interface at one moment, but it cannot reveal hidden state, network responses, event timing, or the implementation behind a label. Your report needs written context as well as a marked picture.

In the fictional Alder Archive catalog, tester Leila selects three print records, applies a subject filter, and sees one highlighted row while the selection counter still displays three. She does not yet know whether hidden selections are intentional, whether the counter is stale, or whether the interface lacks an explanation. Her report asks a focused question: “Should the counter describe visible selections or all retained selections?” She captures the state so the product team can discuss that behavior. The annotation will identify the counter, filter, and visible list, not assert that an unseen database operation failed or that records were deleted.

State the expected behavior separately and say where that expectation comes from. Leila writes that the project acceptance note describes the counter as visible selections, while the screenshot appears inconsistent with that wording. If there is no agreed expectation, frame the report as a clarification request instead of inventing one. This distinction helps engineering and product reviewers decide whether they are looking at a bug, an intentional behavior, or a missing explanation. The annotator does not evaluate software correctness. Its contribution is smaller and concrete: one supplied still image in which the relevant evidence can be found without searching every corner of the interface.

Capture enough context without collecting a whole desktop

Take the screenshot using your device or application before opening the annotator. This tool has no screen capture, scrolling capture, browser extension, live page inspection, or automatic element detection. Choose a capture that includes the symptom and the controls needed to interpret it. For Alder Archive, that means the active filter, selection counter, and visible rows belong together. A tiny crop of the number three would hide the relationship, while a full desktop could expose unrelated messages and make the catalog text too small. Capture the smallest coherent view that still supports the observation rather than the smallest possible rectangle.

Record the reproduction context in text while it is fresh. Leila notes the application revision, browser, window size, filter value, and exact actions that led to the captured state. She distinguishes actions she performed from assumptions about what the system did internally. Her screenshot shows the end state, not the complete interaction sequence. If a problem depends on animation or timing, one still image may be insufficient and another evidence format may be needed outside this editor. Adding numbered circles to the end state does not create a recording of the clicks, preserve timestamps, or prove which event happened first.

Select a still PNG, JPEG, or WebP within the input limits of 15 MiB, a 12000-pixel maximum edge, and 40 megapixels. Preparation creates a PNG within a 2048-pixel edge, four megapixels, and two MiB, so a large desktop capture may be reduced. Check the actual prepared dimensions and whether the important interface text remains legible. The source file on your device is unchanged, but the annotations use the prepared working image. If the counter label is no longer readable, make a better source capture. Heavier arrows cannot recover letters that were too small or lost during preparation of the screenshot.

Mark the relationship between controls and results

Use an arrow for a precise destination, an outline box for a rectangular interface region, an outline ellipse for a compact feature, and a numbered circle for a reference to separate notes. These four shapes are enough for many bug-report screenshots. They do not create clickable hotspots or connect to real controls. Leila starts with an outline box around the counter and an arrow toward the visible selected row. Both marks support the same question about the relationship between the number and the filtered list. She avoids boxing every field, since a report that emphasizes everything no longer tells the reviewer where to begin.

In Draw mode, drag the arrow from its starting point to its tip; drag between opposite corners for boxes and ellipses; click the center for a number. Move selected translates the current mark. Coordinate fields provide a keyboard alternative, using positions across the prepared image with tenths of a percent accepted. Leila positions the arrow beside the highlighted row instead of over the record title. The editor does not snap to interface elements or recognize a button boundary. Confirm that each shape still refers to the intended evidence rather than relying on the precision of the input values to establish semantic accuracy.

Leave space around thin interface features and near screenshot edges. Stroke extents and arrowheads count toward the required image bounds, and very small shapes may fail their geometry requirements. The tool refuses invalid marks instead of clipping them into a plausible-looking proof. If a counter sits near the upper edge, draw a box slightly farther inward or use a pointer from open space. Avoid covering the number being reported. A reviewer should be able to read the original interface value beneath the explanation, not take your arrow as a substitute for the evidence that the screenshot was meant to preserve.

Make numbered notes references, not invented event history

Leila numbers the active filter as 1, the selection counter as 2, and the visible selected row as 3. Her written notes describe what each reference contributes: the active subject filter, the displayed total, and the highlighted row in the filtered list. These are evidence references in one captured state. Her reproduction steps remain a separate list of actions. Keeping the two lists distinct avoids a common ambiguity: a number beside a button can look like an instruction to click it next, even when the report is only identifying a feature visible after the problem has already occurred.

Circle numbers are manual integers from 1 through 99. They do not follow mark order automatically. Move earlier and Move later change stacking only; deleting number 2 leaves number 3 unchanged. Check the image against the reference list after every removal or revision. For this report, Leila keeps the reference identifiers stable while discussing the captured state with the developer. If she takes a new screenshot after the behavior changes, she treats it as new evidence rather than silently recycling an old number list. The tool does not maintain a conversation thread, issue status, or history of the observations behind a mark.

Mark name is for the review inventory and does not become visible artwork text. Naming a box “Counter remains three” does not print that sentence onto the screenshot. Only a numbered circle draws its manual number as text. Write the actual findings, expected behavior, and reproduction steps in the bug report itself. Neutral mark names such as “Selection counter” are easier to reuse in review and avoid putting a conclusion inside a label. The editor permits up to 20 marks, but the three references here already cover the evidence. Additional symbols should earn their place by resolving a genuine ambiguity in the report.

Remove private content before emphasizing the symptom

Screenshots can expose account names, browser tabs, document titles, internal links, notifications, and personal messages outside the feature being reported. Inspect the entire capture before annotation, not just the intended bug region. Leila uses fictional catalog records in a test environment, but a browser notification still shows an unrelated contact name. She creates a separately covered source with the Image Redactor and verifies the edited image before selecting it. An outline is not a privacy cover. It leaves the interior visible, and arrows can make private details easier to notice rather than less accessible.

Do not rely on a numbered circle as a convenient opaque patch over sensitive text. Its purpose is annotation, and this workflow makes no redaction guarantee. Prepare privacy edits with the appropriate separate tool and inspect the actual cleaned source. The annotator exports flattened results but does not judge whether the visible screenshot is safe to share. Fresh export also does not remove information that remains plainly visible in the pixels. Leila checks the cleaned capture at full size before adding references, then reviews it again in the exported proof so the report does not accidentally disclose unrelated content to the issue recipients.

Review mark names and accompanying text as well as pixels. Labels appear in the inventory even though they do not print on the screenshot, so a private account identifier can still escape through a report label. Original filenames and source metadata are not copied into settings or exports, but manually entered labels remain your content. Use neutral names that describe interface regions rather than individuals. The PDF has image-free settings and review attachments, yet its visible annotated proof still shows the captured interface. Image-free attachments do not mean the entire PDF contains no screenshot or that every report artifact is automatically confidential or sanitized.

Preserve legibility instead of decorating the capture

Choose a fixed opaque mark color from violet, forest, ink, or coral. Check it over the full path, especially across dark toolbars and pale content areas. Arrow and outline thickness accepts integer values from 2 through 12 prepared pixels. Number-circle diameter accepts 24 through 160 prepared pixels, separately from stroke thickness. Leila keeps the counter outline thin enough that its label remains readable and makes reference numbers large enough for the report viewer. Do not use color alone to distinguish observed and expected behavior. Object names, numbers, and clear written notes should carry the meaning even when color differences are difficult to perceive.

Before and Annotated help you judge whether the marks reduce searching without obscuring evidence. Both views use the same current source; Before is not a second screenshot or a record of an earlier interface state. Exports always use the annotated version. If the screenshot needs presentation framing for a separate stakeholder document, the Screenshot Beautifier is a different workflow. Keep the original evidence and inspect any presentation derivative separately. A decorative frame is unnecessary for many engineering reports and must not be mistaken for part of the captured application or a way to conceal private content.

Download PNG or JPEG and open the actual file. PNG preserves source alpha except where marks paint pixels, while JPEG is lossy at quality 0.94 and places white behind transparency. Fine interface lettering may look different after JPEG encoding, so check the format you intend to attach. Neither export preserves editable mark layers or the live interface. Leila chooses PNG for this text-heavy capture and confirms that the counter value, filter text, and selected-row highlight remain distinguishable. A valid image export proves that a file was created, not that the report contains sufficient evidence or that the screenshot demonstrates the suspected underlying cause.

Hand off the image with a complete written report

Attach the approved image to a report that includes a concise title, reproduction steps, observed result, expected result, and relevant environment details. Leila titles hers “Selection counter differs from visible highlighted rows after filtering.” She explains that three records were selected before the filter and one remains visible afterward. The image references help the developer find those facts, while the steps make a reproduction attempt possible. Include uncertainty where it remains. The report asks whether retained hidden selections are intended; it does not claim data loss. The annotator cannot create an issue, query application logs, or confirm that another person has reproduced the behavior.

Use the PDF when a readable proof and full mark inventory are helpful for review. It contains the flattened annotated screenshot plus complete inventory, with image-free settings and review JSON attachments. It does not attach the original source image, an unannotated before image, or an editable image project. The proof may be reduced to fit the report, so small interface text can be harder to read there than in the PNG. Screenshot lettering remains raster content rather than searchable report text. Provide essential observed values and their meaning in the written issue, not solely inside a small image embedded on a PDF page.

Full TXT, CSV, and copied inventory outputs preserve the mark information separately. They complement the bug report but do not replace its explanation or reproduction steps. For a description of the evidence image, the Alt Text Writer supports a separate manual writing task. Describe the counter and filtered list relationship instead of listing only “box, arrow, circle.” Image and review outputs require at least one valid mark and a selected image. If a PDF cannot be produced within its supported limits, use the complete alternative inventories with the approved image rather than treating an incomplete or unreadable report as sufficient evidence.

Preserve the evidence and verify each later revision

Save settings stores dimensions and annotation choices without the screenshot or original filename. Keep the cleaned source separately in your own evidence folder. To reopen, select that intended source first and then open settings with matching prepared dimensions. Matching width and height do not identify the image: two different captures of the same application window commonly have identical dimensions. Leila verifies the filter text, counter value, and selected row after reopening. Reusing an old settings file on a new state can place valid marks around completely different facts, so structural acceptance is never a substitute for checking that the evidence still matches the report.

Choosing a new image replaces the source and clears marks after successful confirmation. It does not append another screenshot or preserve annotations as a comparison layer. An invalid or canceled replacement keeps the prior committed image and marks. Save settings can retain a blank draft, but there is no autosave, account storage, or hosted issue archive. A history-restored page may offer Restore image for a source retained in memory; a full reload requires selecting the source and opening settings again. Processing is local without uploading the screenshot, though ordinary website resources still load, so do not describe the whole website as an offline application.

After a fix, capture new evidence and identify it clearly rather than overwriting the meaning of the original proof. The old screenshot records the reported state; the new one may show the intended behavior under the same reproduction steps. This tool does not compare those states automatically or certify a fix. Regenerate image and review outputs after any annotation edit, and replace outdated attachments deliberately because downloads already on the device remain unchanged. The finished handoff should let a reviewer find the symptom, understand the uncertainty, and attempt reproduction. That is a stronger result than an impressive-looking screenshot whose marks conceal the evidence or imply an unverified diagnosis.

Questions about Annotate Screenshots

Continue with another annotation guide

Apply the idea in the Image Annotator, or continue with another explanation guide. Browse more utilities in all free tools.