You spotted six things wrong on a staging page and you have ten minutes before standup. You can hit record, walk through the page, and send a Loom. Or you can grab six screenshots, pin the spots, and send a review link with written notes. Both are valid. They suit different jobs, and picking the wrong one wastes the receiver's afternoon.
Here is how the two formats actually compare on the dimensions that decide which to use.
How long the receiver spends to act on it
A five-minute recording costs the receiver five minutes, minimum. They cannot skim. They cannot search. If the developer wants to recheck issue four, they scrub the timeline and guess. If two people need to act on different parts, they each watch the whole thing.
A still capture with written notes costs the receiver as long as it takes to read. Six items, two sentences each, is a one-minute scan. They can jump to item four directly, copy the text into a ticket, and forward item two to the designer without making the designer watch the other five.
If the feedback is a list of distinct issues, written wins on the receiver's time. If the feedback is one continuous experience that only makes sense in sequence, like an onboarding flow that breaks halfway through a multi-step form, a recording carries information a still does not.
What each format forces you to say
Recording is permissive. You can ramble, hedge, point at the wrong thing, and the video still ships. The receiver inherits your uncertainty. "So this is kind of off, I think, maybe it's the spacing, or maybe the font, I'm not sure" becomes a problem on their desk.
A still capture with a written or dictated comment forces you to commit. You crop to what matters, drop a numbered pin on the exact pixel, and write the sentence. "Pin 1: the submit button is 12px lower than the cancel button on viewports under 1280." That is a specification, not a vibe. It costs you more thought up front and saves the receiver the work of guessing what you meant.
The common failure modes in screen feedback almost all come from skipping that commitment step. Recording makes the skip easy.
Who the receiver is
A developer fixing a UI bug wants the URL, the viewport, the element, and the expected behaviour. They want to paste it into a ticket and move on. Written notes with a still beat a video every time for this audience.
A client reviewing a homepage may prefer a recording because they want to hear your tone and your reasoning. Written feedback can read as colder than you intended. If the relationship matters more than throughput, a video has value.
An AI coding agent cannot watch video at all. It reads text. If the work goes to Claude Code, Cursor, or any other agent, the recording is dead weight. Why Loom does not work with agents covers the mechanics: there is no transcript the agent can ground a code change in, and timestamps are not file paths.
QA teams handing bugs to engineers, agencies handing revisions to designers, and anyone reviewing a staging site before launch are almost always better off with written notes attached to stills.
What gets lost in each format
A still loses motion. If the bug is a janky animation, a hover state that flickers, or a scroll behaviour that only triggers on the third try, a screenshot cannot show it. You can describe it in words, but a recording shows it directly. This is the case where a video genuinely earns its runtime.
A recording loses precision and structure. Eight issues in one video have no identifiers, no separate comment threads, and no way to mark item three resolved while items five and six are still open. The receiver has to invent that structure themselves, usually by transcribing your video into a list, which defeats the point of recording it.
For a more detailed breakdown of when each format earns its place, the screen capture vs screen recording guide works through specific scenarios.
What the receiver does next
The output of a recording is one file. The receiver watches it, takes notes, and creates tickets. Two steps minimum.
The output of a Cobalt Capture review is three things at once: a public link the client or PM can read in the browser, a PDF or Word doc to attach to a contract or ticket, and clean markdown an agent can paste straight into context. The receiver picks the format that fits their next step. The overlap with Loom alternatives shows up here: anything you would have sent as a video, you can usually send as a structured review the receiver acts on faster.
A simple rule for picking
Ask whether the feedback is a list or a story. A list of distinct issues, each on a different part of the screen, is stills with written notes. A story that only makes sense as a sequence (a confusing onboarding flow, a checkout that breaks at step four, a demo of a timing bug) is a recording, or stills plus a short voice note explaining the order.
Ask who is on the receiving end. Developer, agent, or anyone who needs to copy text into another system: written. Client who wants to hear your reasoning, or stakeholder who will not read: video has a case.
Ask whether the bug is motion. If yes, record it. If no, capture it.
When the answer points to written feedback, you can start a review in the browser with no install and no signup. Capture the screen, pin the spots, dictate or type the notes, hit Publish, send the link.