How do I show a client exactly where a bug is without a call?

Take a full-browser screenshot (include the URL bar and page context), annotate the exact element with a red circle or arrow in Preview or Snip & Sketch, and include a one-line description of what it does wrong. Or send a review link where they can see the live page and pin a note directly on the element — no call needed.

How do I get a client to tell me where the bug is instead of just 'it's broken'?

Ask them to share their screen on a quick call, or send them a review link that loads the live site and lets them click the element they mean. Clicking a specific thing is more reliable than asking a non-technical client to describe a page layout — they'll say 'the top section' when they mean the second card in the third row.

Can a client report a bug on a live site without installing anything?

Yes. Tools that wrap the URL (rather than requiring a script tag on the site) let clients open a review link in any browser and click on the page to pin a comment — no extension, no account, no install required.

What should a bug report on a live site include?

Four things: the exact page or URL, the steps that trigger the issue, what the client expected to happen, and what actually happened. A screenshot of the full browser window (not just the error) is the minimum; a screen recording of the reproduction steps is better. The URL bar and any visible navigation matter because they identify the exact page and state.

Does BugHerd require a script tag on the live site?

The BugHerd browser extension works on any site without code changes. The full BugHerd product (with the sidebar widget) requires a script tag or a WordPress plugin installed on the site. If you don't want to touch the codebase, use the extension or a URL-wrapping tool instead.

What's the quickest way to annotate a bug for a developer with no tools?

Full-browser screenshot → red circle in Preview or Snip & Sketch → paste into Slack or email with a one-sentence description. It takes under two minutes and gives a developer enough context to reproduce the issue in most cases.

drafty

How to point at a bug on a live site

Quick answer

To point at a bug on a live site: take a full-browser screenshot and circle the element in Preview or Snip & Sketch, record a screen capture showing the interaction, share your screen on a call, or send a review link your client clicks on the actual page to pin a note right to the broken element. Clicking is more precise than describing.

Step 1

Screenshot and markup the exact element

Open the page, capture a full-browser screenshot (not just the error state — the URL bar, the page title, and surrounding context all help), then open it in Preview on Mac or Snip & Sketch on Windows and draw a red circle or arrow directly on the element. Paste that into your message alongside a sentence describing what it does wrong. The most common mistake here: screenshotting only the error and cropping out the page — so the developer or client can't tell which page, which form, or which breakpoint they're looking at. Include the full browser window.

Step 2

Record your screen showing the interaction

A screenshot shows a state; a recording shows the sequence. Open QuickTime Player on Mac (File → New Screen Recording) or Windows Game Bar (Win + G → Record) and click through exactly what causes the bug — open the page, navigate to the element, trigger the issue. Keep it under 90 seconds. Narrate what you're doing while you record: 'I'm clicking the Submit button after filling in only the first field, and the page refreshes with no error.' A silent recording of someone clicking around a form doesn't tell the viewer what they expected to happen versus what did.

Step 3

Share your screen on a call and point live

For bugs that only appear under specific conditions — a logged-in state, a particular sequence of clicks, a race condition — a Zoom or Google Meet screen share is faster than writing it up. Open the browser, join the call, share only the browser tab so the client sees the exact surface, and walk through the reproduction steps live. This works especially well when a client says 'it's broken' but can't describe how: ask them to share their screen instead, so you're watching the bug happen on their actual device and browser, not guessing at the environment.

Step 4

Send a review link your client clicks on the actual page

The fastest way to get a client to show you exactly where a bug is: send them a link that loads the live site inside a review layer and lets them click the broken element to leave a pinned comment. They don't describe the element — they click it. The note is anchored to that exact spot, so when you open the thread you know precisely which button, which nav link, or which form field they mean. Tools like BugHerd and Marker.io put a script tag on your site; others (including Drafty) wrap the URL so you share a link without touching the codebase. Both approaches beat 'the thing near the top on mobile.'

The faster way

If your client keeps sending you 'the button that doesn't work' over WhatsApp, try dropping the live site URL into Drafty and sharing the link. They open it in any browser — no account, no extension — click the broken element, and leave a pinned note right on it. You see the exact element they meant, reply in the same thread, push the fix on the same link, and mark it resolved. Useful if you're handing off a Figma export, a v0 app, or a hand-built site and you need the client to point at the problem rather than describe it.

Open a live demo

Questions

How do I show a client exactly where a bug is without a call?: Take a full-browser screenshot (include the URL bar and page context), annotate the exact element with a red circle or arrow in Preview or Snip & Sketch, and include a one-line description of what it does wrong. Or send a review link where they can see the live page and pin a note directly on the element — no call needed.
How do I get a client to tell me where the bug is instead of just 'it's broken'?: Ask them to share their screen on a quick call, or send them a review link that loads the live site and lets them click the element they mean. Clicking a specific thing is more reliable than asking a non-technical client to describe a page layout — they'll say 'the top section' when they mean the second card in the third row.
Can a client report a bug on a live site without installing anything?: Yes. Tools that wrap the URL (rather than requiring a script tag on the site) let clients open a review link in any browser and click on the page to pin a comment — no extension, no account, no install required.
What should a bug report on a live site include?: Four things: the exact page or URL, the steps that trigger the issue, what the client expected to happen, and what actually happened. A screenshot of the full browser window (not just the error) is the minimum; a screen recording of the reproduction steps is better. The URL bar and any visible navigation matter because they identify the exact page and state.
Does BugHerd require a script tag on the live site?: The BugHerd browser extension works on any site without code changes. The full BugHerd product (with the sidebar widget) requires a script tag or a WordPress plugin installed on the site. If you don't want to touch the codebase, use the extension or a URL-wrapping tool instead.
What's the quickest way to annotate a bug for a developer with no tools?: Full-browser screenshot → red circle in Preview or Snip & Sketch → paste into Slack or email with a one-sentence description. It takes under two minutes and gives a developer enough context to reproduce the issue in most cases.

Keep exploring

How to collect bug reports from clients How to comment on a live website Review a website BugHerd alternative

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.

Open a live demo