How to Leave Comments Directly on a Live Webpage

Feedback on a webpage is mostly about location — which element, which section, which state. On-page commenting solves that by putting the note on the thing being discussed. This covers how it works, what it replaces, and when it is the wrong tool.

The Problem

Almost all webpage feedback travels through channels that cannot point at anything.

A reviewer sees a problem and has to encode its position in words: “the button in the second card,” “the heading near the top,” “the thing on the right on mobile.” You then decode it. Both steps are lossy, and the failure is asymmetric — you do not find out you decoded it wrong until the next round.

What that costs, concretely:

• A clarifying exchange per ambiguous comment, each one a day of calendar time.
• Fixes applied to the wrong element, discovered a round later.
• Feedback that cannot be found again. The note was in a Slack thread in March. It is functionally gone.
• The same objection raised repeatedly, because nothing recorded that it was raised and answered.

The pattern behind all four: the feedback and the artifact live in different places, and the mapping between them exists only in someone’s head.

How On-Page Commenting Works

The mechanism is a comment layer rendered over the page. Three parts.

1. An overlay, isolated from the page

The commenting UI has to sit on top of the page without interfering with it. Done badly, the tool’s styles leak into the page you are reviewing and reviewers file bugs against the tool.

Undraft renders its overlay in a shadow DOM, which isolates its styles and markup from the hosted page entirely. The page under review behaves exactly as it would without the layer.

2. An anchor per comment

When a reviewer clicks an element, the tool records a reference to that element plus a position. On the next load it finds the element and re-attaches the marker.

This is what makes a comment durable rather than a coordinate on a screenshot. Reopen the same version and the marker is on the element it was placed on, not floating over whatever now occupies those pixels.

3. Threads with a resolved state

Each pin is a thread. Replies attach to it, and it can be resolved.

The resolved state is the part that does the real work. It converts a pile of notes into a checklist with a finish line. A review round is over when every thread is resolved or explicitly declined — and “declined, out of scope” is a legitimate outcome that prevents the objection from resurfacing in a meeting three weeks later.

What to Look For in a Tool

Access should be as close to zero-step as possible. Every step loses reviewers, and it loses the busiest ones first — a client, an exec. An install requirement is the worst offender; a sign-in is survivable if it is one click. Count the steps between “receives link” and “leaves comment” before you commit to a tool.

Comments should survive an update. If a new upload wipes the notes, you lose the record of what was asked for and the version history becomes worthless for settling scope questions. Each version keeping its own comments is the minimum bar.

The page must be genuinely interactive. A tool that annotates a screenshot is annotating a picture. Bugs in a webpage appear when you click, type, and resize.

Hosted review content should be noindex. An unapproved draft of a client page that gets crawled can compete with the real page later. Undraft sends a noindex header on hosted projects for exactly this reason.

When It Is the Wrong Tool

On-page commenting is for feedback where location is the hard part. That is most visual and copy review.

It is not a replacement for:

• An issue tracker. Engineering work needs assignees, estimates, and dependencies.
• A design tool’s comments. If the artifact is a Figma file, comment in Figma. Annotating a rendering of a design is worse than annotating the design.
• A conversation. Some disagreements are about direction, not details. Those need a call, not forty pins.

The signal that you need it: your review threads are full of clarifying questions about where.

Examples

Before

1. You share a hosted page in Slack.
2. Six comments arrive over two days: “spacing feels off,” “not sure about the second heading,” “looks broken on mobile.”
3. You ask three clarifying questions.
4. Answers arrive the next morning.
5. You fix five things, guess on one.
6. Next round, the guess is corrected.

Two rounds and four days for six notes.

After

1. You share the same page with commenting enabled.
2. Six pins land on six elements. The mobile one includes which section.
3. No clarifying questions are needed — the location is in the pin.
4. You fix all six, re-upload to the same link.
5. Reviewers reopen and resolve five, reply on one.

One round, one day, and a record that is still readable next quarter.

Summary

• Put the comment on the element — location is the expensive part of webpage feedback, and pinning removes it entirely.
• Track open threads as your review metric — a round with unresolved threads is unfinished business that will come back.
• Avoid annotating screenshots — interaction is where page bugs live, and a static image hides all of them.

Next: see how it works in practice — comment on a webpage — or start by learning to share an HTML file as a live link.