Does Drafty screenshot my screen when I comment?

No. Nothing is captured from your device beyond the comment itself and a few numbers: viewport width and height, the element's bounding box, and the version id. If an agent later wants to see your view, it re-renders the canvas itself at that width — from the canvas content, not from your screen.

Why does the width matter so much?

Most "looks wrong" bugs are layout bugs, and layout depends on width. A footer that clears its content at 1280px can swallow a whole row at 390px. Without the width, an agent debugs a different page than the one you complained about.

What if I tapped the wrong element?

That's expected — reviewers tap the nearest visible thing, and the real cause is often its container. The tap is treated as a hint, not a verdict: because the comment carries the element's box and the surrounding view, an agent can look at the whole area rather than fixating on the tag you happened to hit.

Why does the version matter?

Canvases iterate fast — by the time someone reads your comment, the page may have changed four times. The comment pins the revision that was actually on your screen, so feedback is judged against the version it was about, and an agent can render that exact version back.

What about comments on images or screenshots?

Comments on an image (like a screen on a site board) also record a precise point within it — the exact spot you tapped, stored as a fractional offset. The agent sees the picture with your point highlighted.

Do old comments have this context?

Comments made before capture shipped simply don't have it — they still work as ordinary threads. Everything new records the context automatically; there's nothing to turn on.

Updated June 11, 2026

What context does a comment capture?

Quick answer

Alongside the words you type, a comment records the view it was made from: the layout width of your screen, the position and size of the element you tapped (including how far you'd scrolled), and the exact version of the canvas you were looking at. That's what lets an agent re-render precisely what you saw instead of guessing from your description. No screenshot of your screen is taken — the capture is a handful of numbers.

When you comment on a canvas, you type a few words and move on. Behind those words, the comment quietly records the view it was made from — the handful of numbers an agent needs to re-render exactly what you were looking at.

What gets recorded

Your layout width (and height) — the single biggest factor in "looks wrong" bugs. A page that's clean at 1280px can swallow a row of content at 390px.
The element's box — where the thing you tapped sat on the page, and how big it was, including how far you'd scrolled.
The version on screen — canvases iterate fast; the comment pins the revision you were actually looking at, not whatever the page says by the time someone reads it.

On images — a screenshot on a site board, say — the comment also records the exact point you tapped within the picture.

What it's for

This is what turns five vague words into a reproducible bug report. An agent reading the thread can render the canvas at your width, at your version, with your element highlighted — and look at the same pixels you complained about, instead of guessing what "squished" means. It can then render again after the fix and check its work against the same view.

The tap itself is treated as a hint, not a verdict: people tap the nearest visible thing, and the real cause is usually a container nearby. That's exactly why the comment carries the surrounding geometry rather than just a tag name.

What doesn't get recorded

No screenshot of your screen is taken, and no image leaves your device. The capture is numbers — a width, a box, a version id. If an agent wants to see your view, it re-renders the canvas content itself; nothing is ever captured from you.

For the full story, see Stop screenshotting other people's websites.

Get started

Frequently asked

Does Drafty screenshot my screen when I comment?: No. Nothing is captured from your device beyond the comment itself and a few numbers: viewport width and height, the element's bounding box, and the version id. If an agent later wants to see your view, it re-renders the canvas itself at that width — from the canvas content, not from your screen.
Why does the width matter so much?: Most "looks wrong" bugs are layout bugs, and layout depends on width. A footer that clears its content at 1280px can swallow a whole row at 390px. Without the width, an agent debugs a different page than the one you complained about.
What if I tapped the wrong element?: That's expected — reviewers tap the nearest visible thing, and the real cause is often its container. The tap is treated as a hint, not a verdict: because the comment carries the element's box and the surrounding view, an agent can look at the whole area rather than fixating on the tag you happened to hit.
Why does the version matter?: Canvases iterate fast — by the time someone reads your comment, the page may have changed four times. The comment pins the revision that was actually on your screen, so feedback is judged against the version it was about, and an agent can render that exact version back.
What about comments on images or screenshots?: Comments on an image (like a screen on a site board) also record a precise point within it — the exact spot you tapped, stored as a fractional offset. The agent sees the picture with your point highlighted.
Do old comments have this context?: Comments made before capture shipped simply don't have it — they still work as ordinary threads. Everything new records the context automatically; there's nothing to turn on.

What context does a comment capture?

What gets recorded

What it's for

What doesn't get recorded

Frequently asked

Related