How to report a bug on a website with a Chrome extension

If you have ever filed a bug report that came back with "can't reproduce," you already know the problem. Steps-to-reproduce written in plain text leave too much room for interpretation. A screenshot in Slack loses the URL, the screen size, the scroll position, and what the user clicked just before the bug happened. By the time the developer asks for more context, the QA engineer (or designer, or marketer) has moved on to the next page.

A Chrome extension solves this by anchoring the bug report to the exact element on the live page — and capturing everything that surrounds it automatically. Here is the workflow.

Why a Chrome extension beats screenshots and Loom

Screenshots show what the page looks like, but not where the user clicked. Loom recordings show the click, but not the DOM, the URL parameters, or the browser size. A Chrome-extension-based bug report combines all three: a pinned marker on the exact element, a written note, and the page context (URL, viewport, browser, OS) collected without the reporter doing anything extra.

That difference matters because most "can't reproduce" tickets aren't because the bug isn't real — they're because the developer is testing on a different screen size, with a different browser zoom, or with a fresh cache. Removing that ambiguity is the single biggest improvement you can make to your bug-reporting workflow.

The six-step workflow

Step 1: Install the Chrome extension

Add Heurio from the Chrome Web Store. It works in Chrome, Edge, Brave, Arc, and any other Chromium-based browser. There is nothing to install on the website itself — no JavaScript snippet, no SDK, no devops ticket.

Step 2: Open the page where the bug appeared

Navigate to the exact URL where you found the issue. This works on production, staging, a Vercel preview deployment, or even a localhost build. Click the Heurio toolbar icon to start a project on the page.

Step 3: Pin the bug directly on the broken element

Switch to Comment View and click the element that's misbehaving — a button that doesn't respond, an image that overflows its container, a form that won't submit. Heurio drops a colored pin (a "heurio") tied to that exact DOM node.

Step 4: Write a reproducible bug report

Inside the pin, write three things:

• What happened — observable behavior. "The submit button does nothing on click."
• What you expected — desired behavior. "The form should submit and redirect to /thank-you."
• Steps to reproduce — a numbered list short enough to test in under 30 seconds.

Add a suggestion (e.g. "looks like the onClick handler isn't bound — check FormSubmit.tsx") and set a severity from Neutral to Critical.

Step 5: Share the project with the developer

Send one URL — the Heurio project link. The developer opens the same page with Heurio installed and sees the pinned report exactly where you placed it, with all the page context (URL, browser, viewport) attached. No JIRA description to write, no annotated screenshot to upload, no "can you DM me the steps again."

Step 6: Track the fix and re-test

Once the developer ships the fix, mark the heurio as resolved. The next time you visit the same project, the resolved pins are hidden by default so you can focus on what's still open. Re-running the report on the next deploy takes minutes, not hours.

Common mistakes that make bug reports unfixable

• Screenshotting the whole window. Pin the specific element instead — the developer needs to know exactly where the issue is, not just "somewhere on this page."
• Skipping the URL. Always file the report on the URL where the bug occurred, not on a related page. Query strings and feature flags often matter.
• Mixing two bugs into one ticket. One bug per heurio. It makes triage and tracking radically easier.
• Vague severity. "Important" means nothing. Pick a level — Critical (blocks release), High (must fix this sprint), Medium (should fix before launch), Low (nice to have), Neutral (FYI).

Why this is faster than the alternatives

Most teams compare visual bug-reporting tools by feature checklist. The bigger difference shows up in how long it takes a non-developer to file a report a developer can act on without asking follow-up questions. With a Chrome-extension-based workflow, that's typically under two minutes per bug, vs. ten or more for the screenshot-plus-Slack approach.

Multiply that by every QA cycle, every client review, every cross-team handoff in a release week — that's where the time savings compound. The reports themselves are also more durable: a Heurio project link still works in three months, while a screenshot in Slack is effectively lost the moment it scrolls out of view.

Get started

If you want to try this workflow on your own site, install Heurio from the Chrome Web Store. The free Starter plan covers most small-team use cases. For organizations, the Professional plan adds unlimited projects, advanced sharing, and team management.