Key takeaways
- Use an arrow when you need to point to one specific element. Use a highlight when the issue spans a region.
- One annotation is almost always better than three. More annotations communicate urgency, not clarity.
- Text labels work when you need to reference multiple things — match each number to a list in the ticket or doc.
- Annotate after you decide the crop, not before — the annotation should match what the final screenshot shows.
Why most screenshot annotations fail
Screenshot annotations fail in two opposite directions:
- Under-annotation: The screenshot shows the right area but there is no annotation. The reviewer has to figure out what to look at. For anything beyond an obvious full-page error, this creates unnecessary friction.
- Over-annotation: Three arrows, a box, a highlight, and a label all on the same screenshot. This signals "look everywhere" which is the same as not annotating at all. The viewer's eye has no clear entry point.
The goal is one annotation that makes the right element impossible to miss, without making the screenshot feel cluttered.
The annotation tools and when to use each
Point to one element
The right default for almost any situation. Draw from empty space toward the element that needs attention. The starting point of the arrow should be in a clear area so the tip reads cleanly against the UI.
Use for: broken elements, misaligned UI, specific buttons or fields, exact pixel locations.
Mark a region
Useful when the issue is not one element but an area — a layout section that is wrong, a group of items that should look different, or a range of content that needs attention.
Use for: layout overflows, misaligned sections, multi-element selections, areas of the page referenced in docs.
Reference multiple things
When one screenshot needs to discuss more than one element, number labels keep things readable. Place a "1" near the first element and a "2" near the second, then reference them in the ticket or doc text.
Use for: multi-issue screenshots, step-by-step walkthroughs, documentation with numbered callouts.
Annotation workflow step by step
- Capture first, annotate second. Take the screenshot, review the crop, and decide what the annotation needs to point to before opening the annotation tools. Annotating before you finalise the framing means the annotation position might not match the final crop.
- Choose one tool and one placement. Ask: where is the single most important thing in this screenshot? Start there. Add a second annotation only if the screenshot genuinely requires it — not because you want to be thorough.
- Position the arrow tip precisely. For arrows, the tip should land exactly on the element — not near it. A vague arrow pointing "somewhere around the top right" is not useful. Zoom in to place the tip if needed.
- Check contrast. The annotation needs to be visible against both light and dark areas of the screenshot. If the arrow blends into the background, adjust the color or add a thin outline so it reads clearly.
- Zoom out and review. Look at the annotated screenshot at the size it will be viewed. Annotations that look large in the editor can look small when the image is displayed at 400px wide in a Jira ticket.
Annotation by use case
Bug reports: One arrow to the broken element. If the bug is a layout issue spanning a section, use a highlight. Export as PNG — do not use JPEG for bug report screenshots, as compression can obscure the exact issue being reported. Full guide: bug report screenshots.
Documentation and tutorials: Numbered text labels work well when a doc section needs to walk through multiple UI elements in sequence. Keep labels small and consistent. If you are annotating a step in a workflow, one arrow per step is cleaner than cramming multiple annotations into one screenshot.
Support and incident response: Same rules as bug reports — one annotation, the most relevant element. If you need to point out sensitive data that should have been redacted, note it in the ticket rather than annotating the sensitive content itself.
Changelog and product announcements: Light annotation or none. Changelog screenshots communicate the improvement through the UI itself. If annotation is needed, a subtle highlight around the new element is usually less intrusive than an arrow.
Common annotation mistakes
- Annotating before cropping. If you annotate and then crop, the annotation may end up cut off or in an awkward position. Finalise the screenshot area first.
- Using a box when an arrow would do. A box around an element takes up more visual space and can obscure surrounding UI that provides context. An arrow points without covering.
- Low-contrast annotation color. A red arrow on a red UI element is invisible. Check annotation color against the actual screenshot background before exporting.
- Too many annotations on one screenshot. If a screenshot genuinely requires more than three annotations, consider whether it should be split into separate screenshots each covering one issue.
FAQ
What is the best annotation for bug reports?
An arrow pointing directly to the broken element. One annotation per bug. If the issue spans an area, use a highlight. See the bug report screenshot guide for the full workflow.
Can I annotate screenshots in Chrome without a separate app?
Yes. FramedShot is a Chrome extension — capture and annotation both happen in the browser without a separate download. See the full annotation feature overview.
How many annotations should a screenshot have?
As few as possible. One is almost always enough. If you need to reference multiple elements, use numbered text labels and match them to a list in your ticket or doc — not multiple overlapping visual annotations.
Capture and annotate screenshots in Chrome — no extra tools needed
FramedShot gives you arrow, highlight, and text annotation directly in the browser. Capture, annotate, and export without leaving Chrome.
Install FramedShot free