A client writes back: "the header needs more space." Which header - the sticky top bar, the section title, the hero band - and on which screen size, given it looks fine on desktop but cramped on mobile? Annotating the live site itself removes that guesswork, because the client points at the exact element on the exact viewport and the comment stays pinned to it.

That is the whole promise of live-website annotation, and it is genuinely better than pasting screenshots into an email thread. But "annotate a live website" hides a few different mechanisms under one phrase, and the mechanism you use decides which pages work smoothly and which ones fall apart. Here is how it actually works and how to do it without the usual surprises.

What "annotate a live website" actually means

At its core, live-website annotation puts a transparent comment layer on top of a real web page. The reviewer opens a shared link, sees your site, and clicks anywhere to drop a pin with a note attached. Instead of describing a location in words - "the second button in the third row" - they point at it directly, and every comment carries the coordinates or the element it belongs to.

The important detail is that the page underneath is your live, rendered site, not a mockup or a static export. That is what makes the feedback unambiguous: the client is reacting to real type sizes, real spacing, real images, at the real breakpoint they are viewing. The catch is that a live page is a moving, interactive thing, and pinning a fixed comment onto something that scrolls, lazy-loads and re-flows is harder than it looks. That is where the two underlying approaches diverge.

Two ways it works under the hood

Almost every tool that does this picks one of two strategies, or blends them. Understanding the difference tells you in advance which of your pages will behave.

Approach How it works Strengths Watch out for
Live iframe Embeds your real page inside a frame and floats the comment layer over it. The reviewer sees the actual, interactive site. Real interaction - scroll, hover, click through states; always current; nothing to re-capture when the page changes. Sites that send an X-Frame-Options or frame-ancestors header refuse to load; mixed HTTPS content and some scripts can misbehave inside a frame.
Screenshot capture A headless browser (typically Playwright) loads the page, renders it, and takes a full-page image that the comment layer is drawn onto. Always renders, even for framebusting sites; a frozen snapshot everyone sees identically; safe to annotate a specific version. No interaction and no live state; content that only appears on scroll, hover or after login can be missing unless the capture handles it.

Neither is strictly better. The iframe keeps the page alive but is at the mercy of what the server allows; the screenshot always produces something to comment on but freezes the page in a single moment. This is exactly why several review tools quietly run a hybrid: try the iframe, fall back to a screenshot when the site blocks framing. If you are weighing up tools, this behaviour is worth checking, and it is one of the axes in our roundup of the best markup.io alternatives for client feedback.

The pitfalls that break annotations

Most "the tool is broken" moments trace back to the same handful of causes. None are exotic, and all are avoidable once you know to look for them.

  • Lazy-loaded images. Modern pages defer images until you scroll near them. A naive capture grabs the top of the page and every below-the-fold image is a blank grey box. The fix is to scroll the full page first so everything triggers before the snapshot is taken.
  • Cookie banners and consent walls. The GDPR overlay that sits on top of the hero is the first thing a fresh browser sees - so it is the first thing your client sees pinned across your homepage. A good capture dismisses or steps past it before recording.
  • Logged-in pages. Dashboards, member areas and checkout steps only render for an authenticated session. A capture with no credentials lands on the login screen instead of the page you meant to review. You need a tool that can authenticate, or a screenshot you supply yourself.
  • Frame blocking. Sites that set X-Frame-Options: DENY or a strict Content-Security-Policy frame-ancestors rule simply will not load in an iframe. If the tool is iframe-only, those pages are dead on arrival; a screenshot fallback is the way around it.
  • Viewport mismatch. "It looks broken" often means "it looks broken on my phone." If everyone annotates at one fixed width, responsive bugs never surface. Reviewing the same page at desktop, tablet and mobile widths is the only way to catch layout that only breaks at a certain breakpoint.

Interactive states deserve a note of their own. Dropdowns, modals, hover menus and multi-step forms do not exist in a single flat snapshot. If a comment needs to land on an open menu, you either need the live iframe so the reviewer can open it, or a screenshot captured with that state already triggered.

A clean annotation workflow

Put the pieces together and a reliable process falls out. This is the sequence that avoids almost every problem above.

  1. Confirm the page is reachable as intended. If it is behind a login, cookie wall or staging password, sort that out first - decide whether the tool logs in for you or whether you will supply the capture.
  2. Load and fully scroll the page before capture. Let lazy content, fonts and animations settle so the version your client sees is complete, not half-rendered.
  3. Dismiss overlays that are not the subject of review. Clear the cookie banner and any intro popups so pins land on the actual design.
  4. Review at more than one viewport. Check desktop and at least one narrow width so responsive issues get their own comments instead of being missed.
  5. Share one link, not a login. The person leaving feedback should click and comment, not create an account. Every extra step between the link and the comment loses a slice of your reviewers.
  6. Keep comments threaded and resolvable. Each pin should hold a conversation and a status, so "done" is visible and nothing gets actioned twice.

Live pages are not the only thing you will collect feedback on, of course. When the deliverable is a proof, a brochure or a contract, the same pin-and-comment idea applies to documents - covered in our guide to PDF markup for client review.

Where Roundmark fits

To be straight with you: this is Roundmark's blog, so of course we think it handles this well. Here is the honest version of what it does. You paste a URL, and Roundmark captures the page - a headless Playwright render plus a canvas overlay - so it works even on sites that block framing. Your client opens one link, with no account and no password thanks to a magic link, and clicks anywhere on the canvas to drop a numbered pin and comment. They can review across viewports, you get threaded replies and resolve statuses, and an AI assistant summarises a pile of comments into a clear action list.

If your work lives inside a bug tracker or you need reviewers to interact with a fully live, clickable page in real time, an iframe-first tool may suit you better, and we would rather you use the right one. But if the goal is to send a client a page and get precise, no-friction feedback back, that is the exact job Roundmark was built for. The free plan gives you three projects with no card required if you want to try it.

FAQ

How do you annotate a live website?

You load the page in a review tool that overlays a comment layer on top, then click any spot to pin a note to it. Under the hood the tool either embeds the live page in an iframe or captures a screenshot to draw on, and each approach has the trade-offs covered above.

What is the difference between iframe and screenshot annotation?

An iframe shows the real, interactive page so reviewers can scroll, hover and click through states, but some sites block being framed. A screenshot is a frozen, reliable snapshot that always renders, but it cannot capture interaction or content that only loads on scroll. Many tools use a hybrid of both.

Why do some pages break when you try to annotate them?

Usually lazy-loaded images that never triggered, cookie or login walls, or headers that forbid embedding. Scrolling the full page before capture, and using a tool that can log in or take a full-page screenshot, resolves most of it.