PictureEditor

Annotation Types Explained

Arrows: Directing Attention

Arrows are the most fundamental annotation tool because they create an unambiguous visual path from a general area to a specific element. The human eye naturally follows the direction of an arrow, making it the most effective way to say "look here" without any text explanation. When annotating screenshots, draw arrows from empty space toward the target element, not from one UI element to another, which creates confusing visual clutter. The arrow's starting point should be in a relatively empty area of the screenshot so the shaft is visible and the direction is clear. Short arrows (under 50 pixels) can be difficult to see; aim for arrow lengths of at least 80-120 pixels for clear visibility.

Rectangles and Circles: Highlighting Regions

Rectangles are best for highlighting UI elements that are naturally rectangular: buttons, input fields, menu items, dialog boxes, and error messages. The rectangle should be slightly larger than the target element with a few pixels of padding on each side, creating a clear highlight without obscuring the content. Circles are better for highlighting specific text, icons, or small elements where a rectangle would be too large. Circles draw attention to a focal point and work well for status indicators, toggle switches, and individual menu items. Use unfilled shapes (outlines only) so the content beneath remains visible. A 2-3 pixel stroke width provides clear visibility without overwhelming the screenshot content.

Text Labels: Adding Context

Text annotations add explanatory context that shapes alone cannot convey. Use text labels to describe what the viewer should notice, what action to take, or why a particular element is important. Keep text annotations short — ideally 3-8 words. Longer explanations belong in the document surrounding the screenshot, not on the screenshot itself. Place text labels near (but not on top of) the element they describe, and use an arrow to connect the label to the element if the relationship is not obvious from proximity alone. Red text on screenshots is a strong convention for indicating problems or errors, while green text signals success or correct states.

Blur: Protecting Sensitive Information

The blur tool is essential for screenshots containing personal data, account information, API keys, email addresses, or any content that should not be shared. Unlike drawing a colored rectangle over sensitive content (which can sometimes be reversed by adjusting image levels), a proper blur permanently destroys the underlying pixel data by averaging pixel values in the blurred region. Once exported, the original content beneath a blur annotation cannot be recovered through any image processing technique. Always blur sensitive information before sharing screenshots in bug reports, documentation, social media, or any public context. Common targets for blurring include email addresses in UI headers, account numbers in financial interfaces, names in user lists, and URL parameters containing tokens or session IDs.

Screenshot Annotations for Bug Reports

The Anatomy of a Good Bug Report Screenshot

A well-annotated bug report screenshot communicates the problem instantly without requiring the developer to read a lengthy description. The ideal bug report screenshot shows the full relevant context (the page or screen where the bug occurs), highlights the specific problematic element with a rectangle or circle, includes an arrow pointing to the exact issue, and adds a brief text label describing what is wrong (for example, "Button unresponsive" or "Text truncated"). The developer should be able to glance at the annotated screenshot and immediately understand where the bug is and what the expected behavior should be.

Annotation Color Conventions

Consistent color coding in screenshot annotations reduces cognitive load for the viewer. The widely adopted convention uses red for problems, errors, and things that need to change. Green indicates correct behavior, expected results, or elements that should be preserved. Blue is used for informational annotations that provide context without implying a problem. Yellow or orange highlights warnings or areas of concern that may or may not be bugs. When annotating a screenshot that shows both correct and incorrect behavior, using red for the problem and green for the expected result creates an immediate visual contrast that communicates the issue without words.

Including Browser and Environment Context

When annotating screenshots for bug reports, include the browser's address bar, developer console, or network tab if they contain relevant information. A screenshot showing a broken layout alongside the console error that caused it is significantly more useful than either piece of information alone. Annotate the console error with an arrow and highlight, then draw a connecting line to the affected UI element. This visual connection between cause and effect saves the developer the time they would otherwise spend reproducing the issue to find the error.

Creating Tutorial Screenshots

Step-by-Step Numbering

Tutorial screenshots benefit enormously from numbered annotations that correspond to written instructions. Rather than describing "click the blue button in the top-right corner of the settings panel," annotate the screenshot with a circled number 1 on the settings icon, number 2 on the relevant tab, and number 3 on the target button. The accompanying text then reads "1. Open Settings, 2. Select the Display tab, 3. Click Apply." This parallel structure between visual annotations and written steps is the gold standard for technical documentation and user guides. Each number should be placed near but not on top of its target element.

Highlighting Navigation Paths

Many tutorial steps require users to navigate through menus, dropdowns, or multi-level settings. Annotate these navigation paths by highlighting the entire sequence: the menu trigger, the submenu item, and the final target. Use connected arrows or numbered circles to show the order. If the navigation requires multiple clicks that change the screen, capture separate screenshots for each state and annotate them consistently with the same color scheme and annotation style. Inconsistent styling between screenshots in a tutorial series forces the viewer to re-learn the annotation system for each image.

Before and After Comparisons

For tutorials showing how to change settings, fix issues, or modify configurations, annotated before-and-after screenshots are more effective than single screenshots. Annotate the "before" screenshot highlighting the element that will change, and annotate the "after" screenshot highlighting the result. Use consistent positioning so the viewer's eye can quickly compare the two states. If possible, place before and after screenshots side by side rather than stacked vertically, as horizontal comparison is faster for the human visual system.

Privacy and Sensitive Data Redaction

What to Blur in Screenshots

When sharing screenshots publicly or in bug reports, systematically check for and blur the following categories of sensitive information: email addresses visible in UI headers or forms, full names of real people (especially in user lists or admin panels), account numbers and financial information, API keys and tokens visible in URL parameters or developer consoles, IP addresses and server names in network requests, and any personally identifiable information protected by GDPR, CCPA, or similar regulations. It is better to over-blur than to accidentally leak sensitive information. A quick scan of every text element in the screenshot before sharing takes seconds and prevents potential privacy violations.

Blur vs. Black Box Redaction

Both blurring and solid-color rectangle redaction effectively hide sensitive content, but they serve slightly different purposes. Blur indicates "there is content here that has been deliberately hidden" while preserving the general layout and visual flow of the screenshot. A solid black or colored rectangle says "this area has been completely redacted." Blur is preferred when you want the viewer to understand that there is a username, email, or value in that location without revealing the actual content. Solid redaction is preferred when even the type of content should be hidden, or when the blur might not be aggressive enough to prevent reconstruction of short text strings.

Common Redaction Mistakes

The most common redaction mistake is using semi-transparent overlays that can be removed by adjusting image brightness and contrast. Always use fully opaque redaction or genuine blur that averages pixel data. Another common mistake is redacting the obvious instance of sensitive data while missing the same data appearing elsewhere in the screenshot — for example, blurring a name in a header but leaving it visible in a breadcrumb, tab title, or sidebar. Always scan the entire screenshot for repeated instances of the same sensitive information. A third mistake is using insufficient blur radius on short text like passwords or credit card numbers, where the character shapes remain recognizable through light blur. Use aggressive blur settings for short, high-value text strings.

Frequently Asked Questions