You open a review from last Tuesday and half the arrows point at empty space. The button they were pinned to moved twenty pixels down, or the copy changed, or the card got a new border, and now the markup that was drawn on the live page floats over nothing. The comment still says "this padding is off," but you can no longer tell which padding it meant.
That is the core problem with annotating a live page instead of a captured frame. The annotation is anchored to a DOM element or a coordinate that keeps moving. The screen you reviewed keeps shipping. The two drift apart, and the drift is fastest exactly where feedback matters most: on the parts of the interface people are actively changing.
Why live-page markup breaks on the next deploy
Tools that draw on the live page have to attach each note to something. Usually that is a CSS selector, an element ID, or an x/y position relative to the viewport. All three are fragile.
A selector like .pricing-card:nth-child(2) becomes wrong the moment a developer reorders the cards or wraps them in a new container. A coordinate breaks when a banner pushes everything down forty pixels. And none of it survives a rewrite, where the whole component gets rebuilt with new markup. Your note about the misaligned label is now attached to a label that no longer exists.
This is not a rare edge case. It is the normal life of a staging site or a build in progress. The screen you review at 2pm is not the screen your teammate loads at 5pm. Anything pinned to the live version inherits every change made between those two moments, whether or not the change had anything to do with your feedback.
Why a cropped still holds its meaning
A captured frame does not move. It is a picture of exactly what you saw, at the moment you saw it, and nothing on the real site can change it afterward. Six weeks later the still shows the same broken layout you were describing, so the comment beside it still lands.
That permanence is the whole reason a still frame beats a video for written feedback too. A recording forces the receiver to scrub for the frame you meant; a still is already that frame. The full argument for one over the other is laid out in the guide on screen capture versus screen recording, and the short version is that a fixed frame with text next to it is faster to act on than anything the receiver has to replay.
Cobalt Capture leans into this on purpose. You click Capture screen, the browser draws the current frame to a canvas, and you drag a rectangle to crop it down to the part that matters. Cropping the still is the only image edit, which sounds like a limitation and is actually the point. There is nothing anchored to the live DOM to go stale. The evidence is baked into the image.
When you need to say exactly where on that frozen frame, you drop a numbered pin on the screenshot. The pin lives on the still, not on the page, so it points at the same spot forever. "Pin 2, the discount code field, wrong tab order" reads the same today and after three deploys.
What this changes about how you write feedback
Once the frame is frozen, your comment can be specific without hedging. You are not writing "the button near the top, currently," hoping the reader finds it before it moves. You are writing about a picture you both see. Type the note or dictate it with the browser's speech recognition, and the meaning is locked to the image.
This matters most in two workflows. On a staging site being reviewed before launch, the build is changing under you by the hour, and live-page markup would be stale before the developer even opened it. In collecting client feedback, the client reviews on Monday, the developer picks it up Thursday, and by then the site has moved on; a still keeps the client's exact view intact for whoever reads it later.
The receiver's format also stays clean. On Publish, the review gets a short public link at /r/<slug>, and the same review exports as PDF, as a Word document, or as plain markdown. Each of those carries the cropped still and the comment together. Nothing in any of them depends on the live site still looking the way it did, which is what makes a review readable a month after you wrote it.
When you would still want the live page
There is one honest case for annotating live: when the thing you are reviewing is behavior, not a moment. Hover states, animation timing, a form that only breaks after three submits. A still cannot capture a sequence.
But even then, the fix is usually to capture the specific frame where the behavior goes wrong and describe the steps in the comment, rather than to pin markup to a page that will not hold it. A frozen frame plus "click submit twice, then the error appears on the third" survives the deploy. Live markup of the same bug does not.
If your reviews keep going stale between capture and fix, stop drawing on the moving target. Start a review, crop the frame, and let the still do the remembering.