What is visual bug reporting?

A plain explanation of what a visual bug report contains, how it is captured and where it stops being enough.

Visual bug reporting is filing a bug by showing it rather than describing it. The reporter marks up a screenshot or recording of the problem, and the tool attaches the technical context automatically: page URL, browser, device, console messages and network requests. Developers get evidence they can reproduce instead of a vague written description.

The problem it solves

Most bug reports start as a sentence: "the checkout is broken". To act on it, a developer needs to know which page, which button, which browser, what the person expected and what actually happened. Getting that usually takes two or three rounds of questions, and by then the reporter has forgotten the details.

Visual bug reporting removes most of that back-and-forth. The reporter points at the problem on the screen, and the software fills in the details a non-technical person would never think to include.

What a visual bug report contains

  • The picture: a screenshot of what the reporter saw, with boxes, arrows, freehand marks or text drawn on it. Some tools also offer a short recording of the steps.
  • The words: a title and a short description, written by the reporter. The picture carries most of the meaning, so these can be brief.
  • The page: the exact URL and page title, so nobody has to guess where it happened.
  • The environment: browser and version, operating system, viewport and screen size, pixel ratio, language and time zone. Layout bugs often depend on these.
  • The console: recent JavaScript errors and log messages from the page.
  • The network: recent requests the page made, with method, URL, status and timing, so a failed API call is visible.
  • Triage fields: priority and a category, so the report reaches the right person.

Written report versus visual report

Question a developer asksWritten reportVisual report
Which part of the page?Described in words, often ambiguouslyCircled on the screenshot
Which browser and screen size?Usually missingAttached automatically
Was there a JavaScript error?The reporter cannot tellIn the console log
Did an API call fail?Invisible to the reporterIn the network log, with the status code
What did they do first?Recalled from memoryShown in a recording, where the tool supports it

Three ways reports get captured

A widget on the website. A small script adds a "Report a bug" button to the site. Anyone visiting, including clients and customers, can use it without installing anything. Because the script runs inside the page, it can see console messages and network requests.

A browser extension. Team members install it once and can report on any site, including ones where you cannot add a script. It usually needs a sign-in and permission to read the page.

An SDK inside a mobile app. The same idea for native or cross-platform apps: a shake or a floating button opens the reporter, and the SDK attaches the device, the current screen and recent logs.

Where visual reporting falls short

A screenshot shows the symptom, not the cause. For bugs that live entirely on the server, such as a wrong calculation in a nightly job or a slow database query, the picture adds little and your server logs and error monitoring do the work.

It also cannot capture what the browser never saw. Request and response bodies, server stack traces and other users' data stay out of a client-side report, which is usually what you want for privacy, but it means the developer may still need to look elsewhere.

Privacy is part of the job

A screenshot can include names, emails, order details or anything else on the screen. A good tool lets the reporter hide sensitive areas before the report leaves the browser, masks typed values in recordings, and only accepts reports from websites you have approved.

Flawsnap's Blur tool pixelates areas in the browser before upload, and a project only accepts reports from the domains you list. See screenshot annotation.

How Flawsnap does it

Flawsnap is a visual bug reporting tool for websites. You add one script tag, visitors circle the problem, and the report arrives on your team's board with the annotated screenshot, console, network calls and device details. Screen recordings and the AI connectors are on the Pro plan. The Chrome extension lets your team report from any site with no code on it, and the Flutter SDK for iOS and Android apps is on pub.dev. You can try the widget on the demo shop.

Questions

Is visual bug reporting only for testers?
No. It is most useful for people who are not technical, such as clients, customers and support staff, because the tool collects the technical details they would not know to include. Testers and developers benefit too, since the reports are consistent.
Does a visual bug report replace error monitoring?
No. Error monitoring catches crashes and exceptions automatically, including ones nobody reports. Visual bug reports capture problems a person noticed, including ones that throw no error at all, such as a wrong price or a hidden button. Most teams benefit from both.
Do reporters need to install anything?
Not with a website widget: the button is part of the page. Browser extensions need a one-time install, and mobile apps need the SDK built in by the developers.
Can a visual report include a video?
Many tools offer recordings. Some record actual video of the tab; others record a replay of the page's structure, clicks and scrolls, which is smaller and can mask typed text. In Flawsnap, recordings are on the Pro plan.

Try it on your own site

7-day free trial, then $9 a month for Starter or $19 for Pro, per organization, with unlimited team members.

Updated