CAPTURE & HANDOFF

Make a screenshot that helps someone reproduce the bug.

A marked-up image shows where to look. The route, page state and expected behavior explain what to fix. Use both so the next person can reproduce the problem without a screen-sharing call.

An overlapping form error is marked once and linked to notes describing its location, actual behavior and expected result.
Illustration: Pair one focused annotation with the page state, reproduction steps and expected behavior.
01

Reproduce one issue

Record the route, browser, viewport and actions that reveal it.

02

Capture and annotate once

Keep enough context, point to the problem and add a short note.

03

Verify the correction

Repeat the original steps after the source change and check nearby states.

Describe the problem before reaching for the arrow tool

Write one sentence with a trigger and an observable result. “On /signup at 390 CSS pixels wide, submitting an empty email field makes the error overlap the password label” gives a developer a starting point. “The mobile form looks wrong” does not.

Keep separate defects separate. A font mismatch, a broken submit action and an overlapping error message may need different owners and different fixes. One report can link to the others, but its screenshot should have a clear main subject.

Capture the state that exposes the issue

Open the menu, trigger the error or choose the long option before taking the screenshot. Record the viewport in CSS pixels and the browser version. If the issue depends on zoom, language or a signed-in state, include that condition without sharing credentials.

Use Snip & capture for a precise region or Pick an element for a component with a useful boundary. Keep nearby labels and headings when they help identify the location. For a page-wide layout problem, include an overview plus a readable detail rather than one enormous image with tiny text.

Choose the right capture mode

Investigate sideways scrolling before filing the report

Use one annotation to direct attention

In the capture editor, adjust the crop first, then open Edit. Add one arrow, rectangle or short text note. Put the note in nearby empty space so it does not cover the defect. If you need many marks, consider whether you are describing several issues at once.

Describe the expected relationship rather than an arbitrary visual preference. “The next field moves down when the message wraps” is more actionable than “add some space.” Use measurements when the spacing itself is the issue, and state whether they are observed values or proposed targets.

Crop and annotate in the editor

Record a spacing issue accurately

Copy this report template

The following example separates facts, expectations and verification. Replace each value with what you observed. Include reproducibility, such as “every time after a fresh load” or “only after switching plans,” instead of suggesting certainty when the problem is intermittent.

website-bug-report.txt
Title: Signup error overlaps the next field at 390px
URL / route: /signup
Browser and version: record the tested browser
Viewport: 390 × 844 CSS px
State: signed out, default language, browser zoom 100%

Steps
1. Open /signup.
2. Leave the email field empty.
3. Submit the form.

Actual: Error text overlaps the password label.
Expected: The error wraps and the next field moves down.
Frequency: Every time in this test.
Attachment: signup-empty-email-390px.png

After the fix
Repeat the steps at 390px and nearby widths.
Check keyboard focus and a longer error message.

Keep the evidence readable and safe to share

Use a test account and non-sensitive sample data when possible. Remove personal details, tokens or payment information before capture. A blur effect is not a reliable substitute for removing secrets, and a full-page image can include content outside the part you were concentrating on.

Export the original file and inspect it at 100%. Use a descriptive filename, but leave account identifiers out of it. If the issue is an animation or a brief interaction, a still image may need a separate recording and written timing information; do not expect one screenshot to prove a sequence.

Make sure the delivered attachment stays readable

Close the report with the same test

After the source change, return to the original route, viewport and state. Repeat the same steps before comparing screenshots. A different viewport or shorter error message can hide the defect and make an unfixed issue look resolved.

Keep a before-and-after pair when it helps the reviewer understand the change. Then test one nearby width and one harder content case. For the form example, use a longer error and tab through the controls. Record what passed and any limits of the test instead of saying that the whole website is now bug-free.

Using these tools in Sitepeel

The Sitepeel steps below describe the 1.0.3 tools. Preview 1.0.3 here. Browser-store availability may vary while the update rolls out. Try them on public Sitepeel pages in the website demo; use the installed extension for other websites. Changes made with inspection and preview tools do not publish changes to a website.

A few useful answers.

Is an annotated screenshot enough to report an interaction bug?

Usually include steps and expected behavior as well. For a brief or animated problem, a recording may provide evidence a still image cannot show.

Should I add a decorative browser frame to a bug report?

Only if it helps. For layout debugging, an unframed crop with dimensions and one annotation is often easier to inspect.

TAKE A CLOSER LOOK

Your next starting point is already on the web.

Inspect it. Understand it. Build something of your own.

Add to ChromeFree installExplore all 13 tools