You spotted a broken button on a staging build. The instinct is to grab a screenshot tool, draw a red arrow, type a caption next to it, and send the file. That works, but it is slower than it looks, and the arrow rarely says everything you meant. There is another way to point at the exact thing you mean without drawing on the image at all.
In Cobalt Capture the only image edit is cropping the captured still. No arrows, no boxes, no text stamped on the pixels. That sounds like a limitation until you try it. Cropping tight, dropping a numbered pin, and speaking your comment turns out to carry more precise information than a hand-drawn scribble, and it does it in a browser tab with no install.
Start with the capture, not the drawing tool
Open a new review and click Capture screen. The browser asks which window or screen to share, and the current frame gets drawn to a canvas. That frame is your raw material. You are not marking up the live page; you froze a still of it, which means the layout can shift, the page can reload, and your reference stays fixed.
This is where cropping does its first job. Drag a rectangle around the region that matters. If the bug is a misaligned price in a pricing table, crop to the table, not the whole 1440-pixel viewport. A receiver opening your review sees the table filling the frame instead of hunting for it inside a full-page screenshot. The crop is your first act of pointing.
Use numbered pins to say exactly where
A crop narrows the area. A pin marks the spot. Each screenshot can carry numbered pins that sit on specific coordinates, so instead of writing "the button near the top right," you drop pin 1 on the button and let the number do the pointing.
Numbers also carry order. If a screen has three problems, pin 1, pin 2, and pin 3 tell the reader the sequence to read them in. A developer working through your feedback reads pin 1, fixes it, reads pin 2, and never has to guess which comment goes with which spot. That is the whole point of numbered pins that make a developer read steps in order: the geometry and the sequence are baked in, not described in prose.
Compare that to a drawn arrow. An arrow points, but it does not number, and when you have four arrows in different colors the reader still has to match each one to its caption. Pins remove that matching problem.
Say the comment out loud
Each pinned screenshot becomes an item, and you attach a comment to it by typing or by dictating with the browser's built-in speech recognition. Dictation is where the drawn-label habit really breaks down. A text label on an image has to be short or it covers the thing you are describing. A spoken comment has no such limit.
So say what you actually mean: "Pin 1 is the Subscribe button. On desktop at 1440 it sits 12 pixels below the divider, which reads as detached from the plan card above it. It should hug the card the way the monthly plan does." That is three sentences of context you would never cram into an arrow caption. Dictation runs in Chrome and Edge; if your reviewer is on Firefox they type instead, and the item structure is identical either way.
The full method of replacing drawn markup with a crop, a pin, and a spoken note is what the annotate a screenshot approach is built around. You get precision without ever fighting a drawing cursor.
Why the cropped still beats marking the live page
Some tools let you draw directly on the live page in a browser. That feels more direct, but the annotation is tied to a page that keeps changing. Reload it and your marks can drift or vanish. A cropped still is frozen. It shows the exact state you saw, including that one render where the layout broke. The reasoning behind why a cropped still beats an annotated live page comes down to this: a still is evidence, and evidence should not move.
You can also mix in items that have no screenshot at all, just a floating comment, for a note like "the whole onboarding flow assumes the user already connected their calendar." Not every point needs a picture.
Publish and hand it off
Click Publish and the review gets a short public URL at /r/<slug>. Anyone with the link opens it in a browser, reads your crops and pins, and posts a comment on any individual item. You mark each one resolved as it gets handled, which covers triage without a separate bug tracker.
The same review is available as a PDF, a Word document, and clean markdown at /r/<slug>/markdown. That last format matters if the work goes to an AI coding agent: the markdown lists each pinned item and its comment in a structure the agent reads directly, so a tool like Cursor gets the same precise pointing your human reviewer sees. One capture, every receiver served.
Next time you reach for the arrow tool, stop. Crop tight, drop a pin, say the sentence you were about to abbreviate, and publish. The receiver gets something clearer, and you spent less time getting there.