Isn't a screenshot with an arrow drawn on it the same idea?

It is the same instinct and about half the job. A screenshot is a picture of a page, detached from the page: no URL unless your client typed one, no width, no element, no status, and no way to tell that today's screenshot is about the same button as last week's. A pin keeps the instinct and keeps the address with it, which is the part you need three days later.

Can my client leave a pin from a phone?

Yes. Review happens in the browser, so there is nothing to install on their side, and it works from a phone. The device is recorded with the comment as mobile, along with the viewport width, which matters because a spacing complaint at 390 pixels is a different job from the same complaint at 1440.

Do I have to install anything on the site being reviewed?

Not for a shared review link. Writhink loads the page through its own proxy so pins can attach to elements, and the site itself is untouched. You only add a script tag if you want the always-on widget, and you only install the Chrome extension when the page is behind a login or on localhost.

Can two people annotate the same page at once?

Yes, when the project owner turns live collaboration on. You see who else is in the review, their cursors, and pins as they are placed. With it off, everyone can still comment, you just do not see each other in real time.

Can a client edit a pin they left?

Yes, their own comments only. Ownership is proven by a token stored in their browser, which is what makes editing possible without an account. The trade-off is that a comment left on their laptop cannot be edited from their phone.

What is an element anchor?

A reference to the element the pin was dropped on, stored alongside the click position and resolved again each time the review is opened. It is the difference between 'the annotation is at 980 by 412' and 'the annotation belongs to this button'. Only the second one still means anything after the layout moves.

What happens to old annotations after a redesign?

If the element they point at no longer exists, the anchor cannot match it any more. The comment does not disappear: the screenshot, the page URL, the viewport, the device type and the whole thread remain, which is usually enough to tell what was being asked for. That is the reason the screenshot is automatic rather than something your client has to remember to attach.

What exactly does the automatic screenshot capture?

The pinned spot on the page, taken at the moment the comment is left. It travels with the item, including into the generated AI prompt, so the request stays readable even after the page it was left on has changed.

Website feedback

Point at the thing you want changed

Written feedback loses the one detail that matters most: which element. Writhink puts the comment on the page instead, pinned to the exact button, heading or image it is about. This page covers both halves: why pinning beats describing, and what each annotation stores so it still points at the right thing after the page has reflowed, re-rendered or been rebuilt.

Pin your first comment

No credit card. Your client doesn’t need an account.

Which button?

A client writes: 'the button is too close to the text and the color is off'. The page has three buttons. Two of them live in a component that also appears on four other pages. The client was on a laptop, and the spacing they are complaining about only looks wrong below 1200 pixels. You now have a twenty-minute conversation ahead of you, or a guess, and the guess costs a round.

This is not clients writing badly. It is that language carries no reference to an element on a page. Every phrase people reach for to point at one, 'the header', 'that box', 'the bit at the top', is ambiguous the moment you are not looking at their screen with them.

Visual feedback removes the pointing problem instead of asking people to describe things more precisely. The comment is placed on the element. Nobody has to name it.

One note, and the same note as pins

Here is a message of the shape everyone gets on a Friday afternoon. 'Hi! Looks great overall. Just the button is a bit close to the text and the colour looks off to me. The header also feels cramped on my screen. Thanks!'

Before you can touch any of it you have to establish five things by asking: which of the three buttons; whether 'the text' is the heading above it or the paragraph beside it; what 'off' means, since it could be the shade, the contrast against the new background, or the fact that it no longer matches the hover state; which header, on which page; and what 'my screen' was, because the cramping only happens under a certain width. That is a reply cycle, and the answers come back two days later from memory.

The same note left as pins is three items and no questions of that kind. One sits on the button in the pricing hero, screenshot attached, left at 1280 pixels on desktop, saying the gap above it is too tight. A second sits on the same button and says the fill is too pale against the section behind it. A third sits on the header of the same page at the same width. Nothing has to be established. The questions that remain are real design questions, how much tighter and how much darker, and they get asked in the thread under the item, where the answer stays.

That is the whole argument. Pinning does not make your client more articulate. It removes the part of the message they were never going to get right, and leaves them the part they are actually the expert on.

The same request, sent two ways

What you need to know	Sent as a message	Left as a pin
Which element	'the button', 'that bit at the top'	The pin sits on the element itself and stays with it when the page reflows
Which page	Whatever the sender remembered to mention	The page URL, recorded automatically
Which screen size	Unknown, usually whatever laptop they had open	The viewport width, plus desktop, tablet or mobile
What it looked like at the time	A cropped screenshot, if you are lucky	A screenshot of the pinned spot, captured automatically
Whether it is still open	Buried somewhere in a thread	A status: open, in progress, in review, resolved
What the answer was	In your sent folder	A public reply in the thread under the item

What leaving a pin looks like from the other side

Step 1
Open the link
No account, no download, no app. Your client types a display name and that is the whole setup. No email address is asked for and nothing needs verifying.
Step 2
Click the thing
They click the element they want changed and a pin appears on it. The page, the width they are viewing at and whether they are on desktop, tablet or mobile are recorded with the comment. They type none of that and are not asked about any of it.
Step 3
Say what is wrong
Free text, plus up to five attachments of 10 MB each when a reference image helps. A screenshot of the pinned spot is captured with the comment, so the item still makes sense when you read it three days later.
Step 4
Carry on
They can reply in the thread and edit or delete their own comments. If live collaboration is turned on for the project, they also see who else is in the review, their cursors, and pins appearing as they are placed.

Where a pin can go

Pinning is not limited to a public page in a browser tab. Choosing between the routes is covered on /website-feedback-tool.

Any page Writhink can load from a URL: a live site, a staging build, a client preview. Nothing installed on either side.
Screens that only exist after a login, plus builder previews and localhost, through the Chrome extension. Chrome only.
Your site or your client's permanently, through the embedded script widget, so a comment can be left the day something is noticed rather than only during a round.
PDF pages and image sets, pinned and threaded the same way, with the page number stored on each comment.

What is stored with every annotation

Stored	Why it is there
Pin position	Where on the page the person clicked
Element anchor	A reference to the element under the pin, so the annotation belongs to the button rather than to a pair of numbers
Page URL	Which page of the site the annotation was left on
Page number	For a PDF review, which page of the document
Viewport size	A spacing or wrapping complaint only means something at a width
Device type	Desktop, tablet or mobile. The same layout collects different complaints on each
Screenshot	Captured automatically at the pinned spot, so the item survives changes to the page
Attachments	Up to five files at 10 MB each, when a reference helps more than a sentence
Thread and status	The public replies underneath, and whether the item is open, in progress, in review or resolved

Device type means desktop, tablet or mobile, and nothing finer. Writhink does not record the operating system, the browser or the model of the handset.

Scrolling, resizing, re-rendering, and where an anchor gives up

Scrolling changes nothing. The annotation is attached to its element, so it travels with the page rather than floating over the window, and a pin left on the footer is still on the footer when you scroll back down to it.

Resizing changes the layout, not the ownership. The pin stays with its element wherever the reflow puts it, and the viewport recorded on the comment tells you which width the complaint was made at, so you can go back to that width to see what your client saw.

Re-rendering is the case people expect to break and it usually does not. When a framework swaps a node for a fresh instance of the same component, the element still sits in the same place in the document, so the anchor resolves to the new node and the pin lands where you expect. What actually breaks an anchor is not the node being recreated, it is the structure around it changing.

Which brings the limit, and it is structural rather than a bug to be fixed. If the element itself is gone, because the section was rewritten or the component replaced with a different one, no anchor can point at it any more. That is exactly why every annotation also carries a screenshot and the page URL: the reference degrades from 'this element' to 'this is what it looked like and this is what was asked for', which is still enough to act on. Nothing is lost, the pin just stops being clickable.

Annotating the same screen at three widths

Device-specific annotation is a technique, not a switch you flip. What makes it work is that each comment remembers what it was made on.

Do a pass at desktop width, then reopen the same page narrow and do another. Each comment keeps its own viewport size and device type.
The two passes produce different findings. Tap targets and stacking order only fail narrow; line length and column rhythm only fail wide.
Every comment carries its own screenshot, so 'this is too tight' at 390 pixels is never read as the same request as one made at 1440.
Your client can annotate from their phone directly. It runs in the browser, so there is nothing for them to install, and the device type is stored with the comment.
What is stored is the width and the class of device, not the handset. An annotation will tell you it was left on mobile at 390 pixels; it will not tell you which phone or which browser.

An AI cannot ask you which button

When a person implements the change, ambiguity costs a message. When an AI implements it, ambiguity costs a wrong diff, because an assistant fills the gap with something plausible rather than stopping to ask.

That is the practical argument for pinning. Each item in the generated prompt keeps its element, its page, its viewport and the URL of its screenshot, so the assistant works from a reference rather than a paraphrase. Anything still ambiguous after Writhink rewrites the comments is flagged as unclear and left for the client to answer, and the prompt ends by asking the AI to draft those questions for you.

What the rewrite can and cannot recover is set out on /feedback-to-prompt: it can make a sentence unambiguous, it cannot add the element, the page and the width back in, which is exactly the gap this page is about.

Pin it, or write it out

A pin is the right shape for

Spacing, alignment, color, type: anything you can see
A copy change on one specific line
A component that is wrong on one page and fine on another
A layout that breaks at one width and holds at the others
'This one, not the other three'

Write it out instead when

The request changes the structure, not a page: 'split the checkout into two steps'
The problem is behavior you cannot point at, like a slow response or a form that fails on submit
It is a scope or budget conversation rather than a change to an artifact
Finding it needs tooling rather than eyes, such as a performance profile

Before you count on it

Writhink is in open beta: everything described here is available and free, no credit card. Paid plans are announced but not purchasable yet. The one limit that applies today is five AI prompt generations a month per organization.

FAQ

Questions people actually ask

Isn't a screenshot with an arrow drawn on it the same idea?: It is the same instinct and about half the job. A screenshot is a picture of a page, detached from the page: no URL unless your client typed one, no width, no element, no status, and no way to tell that today's screenshot is about the same button as last week's. A pin keeps the instinct and keeps the address with it, which is the part you need three days later.
Can my client leave a pin from a phone?: Yes. Review happens in the browser, so there is nothing to install on their side, and it works from a phone. The device is recorded with the comment as mobile, along with the viewport width, which matters because a spacing complaint at 390 pixels is a different job from the same complaint at 1440.
Do I have to install anything on the site being reviewed?: Not for a shared review link. Writhink loads the page through its own proxy so pins can attach to elements, and the site itself is untouched. You only add a script tag if you want the always-on widget, and you only install the Chrome extension when the page is behind a login or on localhost.
Can two people annotate the same page at once?: Yes, when the project owner turns live collaboration on. You see who else is in the review, their cursors, and pins as they are placed. With it off, everyone can still comment, you just do not see each other in real time.
Can a client edit a pin they left?: Yes, their own comments only. Ownership is proven by a token stored in their browser, which is what makes editing possible without an account. The trade-off is that a comment left on their laptop cannot be edited from their phone.
What is an element anchor?: A reference to the element the pin was dropped on, stored alongside the click position and resolved again each time the review is opened. It is the difference between 'the annotation is at 980 by 412' and 'the annotation belongs to this button'. Only the second one still means anything after the layout moves.
What happens to old annotations after a redesign?: If the element they point at no longer exists, the anchor cannot match it any more. The comment does not disappear: the screenshot, the page URL, the viewport, the device type and the whole thread remain, which is usually enough to tell what was being asked for. That is the reason the screenshot is automatic rather than something your client has to remember to attach.
What exactly does the automatic screenshot capture?: The pinned spot on the page, taken at the moment the comment is left. It travels with the item, including into the generated AI prompt, so the request stays readable even after the page it was left on has changed.

Start

Send one link. Get feedback you can build from.

Your clients comment right on the page — no account, no screenshots, no voice notes. Writhink sorts the comments and writes the prompt for your AI.