Edit and keep your work

Prepare a screenshot for a useful website bug report

A bug screenshot is most useful when it belongs to a reproducible procedure. Prepare the page state before drawing annotations.

Record state and steps

Note browser version, page state and the steps that led to the issue. Mention whether it depends on login, a selected filter or an open overlay without including passwords or session data. A screenshot alone does not explain every condition.

Use a normal page with the issue already visible. If its layout depends on width, note the window or viewport used. Do not change zoom, resize or navigate during a full-page capture.

Explain one issue clearly

  1. Capture the relevant view with enough context.
  2. Add one arrow or rectangle and a short factual label.
  3. Write expected behaviour separately from what the image actually shows.
  4. Download and inspect the file, then remove private information before sharing.

Keep annotation and observation separate

An arrow can identify a clipped label; it cannot prove why clipping happened. Avoid labels that invent a technical cause. Use “label clipped after opening menu” instead of an unverified diagnosis. Keep the original capture separately when it helps later review.

Choose the next step from the actual result

Keep the smallest procedure that reproduces the visible problem. Long sequences can introduce unrelated page changes and make the image difficult to interpret. Distinguish an issue already visible on the original page from one introduced by an incomplete or changing capture. If the original is correct but the screenshot has a missing section, report the capture behaviour rather than a website layout defect.

A useful report pairs the image with a short written observation. Name the field or section, the action and the resulting state. Keep expected behaviour separate. If several defects are visible, prioritise one in the annotated file and describe others separately. Review the final export at the destination’s likely size. A full-resolution file may help when ticket thumbnails make small labels unreadable.

A worked example

A form error overlaps a submit button after a dropdown opens. Capture the open dropdown and the error in one visible view. Label the overlap and list the three steps that produced it. A second image of the closed dropdown can provide comparison, but each file needs a clear state label.

Add your observations. This template processes no files and sends no report.

Check the result

If something is wrong

Observation and next step
ObservationNext step
Image lacks the relevant stateReproduce the issue before capturing and keep the required overlay open.
Annotation invents a causeRewrite it as the visible observation and leave diagnosis open.
Sensitive account information visibleUse a non-sensitive sample or a reviewed permitted redaction workflow.

Common questions

Does this send a support ticket?

No. The template is local preparation; you decide where to share it.

Is a screenshot enough to prove the cause?

It records a visible state. Reproduction steps and additional investigation are still needed.