A screenshot is a quick way to show someone what happened on your screen. If the error is unreadable on a phone or the recipient cannot work out which button to look at, it makes the exchange slower for both of you. A useful screenshot starts with the recipient's question. Show the area needed to answer it and write out any important text separately.

Decide what you want to show first

For a bug report, the recipient usually needs to know what you were trying to do, where you got stuck and what the screen said. In a design review, the key details are which part should change and how it sits alongside the surrounding elements. Try writing that purpose in one sentence. For example, “The upload button stayed disabled after I selected a file” points to the part of the screen worth capturing.

Capture just the relevant window when it contains everything the recipient needs. If an error appears in a corner and its connection to the form is unclear, use two images. Show the form in the first and give the error a closer crop in the second. File names that reflect the order help the recipient match the two images.

Make the text readable before cropping

Zoom in before taking the screenshot if the page allows it. Zooming can change the menu or move controls down on narrow layouts. If you are reporting a problem that only happens at a particular width, take an overview at that width. Add a detail image in which the text can be read if needed. Enlarging an image that has already been saved at a small size cannot recover lost pixels.

When explaining a menu, retain its heading or the preceding step alongside the option. For a table row, include the column headings that give it meaning. If the crop makes little sense on its own, provide a short description in the message. “The Notifications tab in Settings” can be more helpful than leaving the entire top half of the screen in the image.

Pair annotations with written instructions

Mark a button with a thin outline or place a marker beside it. Check that the marker leaves the label, error code and keyboard focus visible. For several steps, use the same numbers in the screenshot and in the explanation. If you use colour, add a shape or a number so readers can identify the relevant detail without relying on colour alone.

Copy the exact error text into the message when you can. The recipient can then copy it or search for it later. On a help page, include the essential information from a screenshot in the page text too. A short text alternative can describe the purpose of the screenshot without repeating steps the page already provides. W3C guide to images and text alternatives

Review the final file for private details

Tab names, the address bar, notifications, account information and open chats can all slip into a capture. Crop areas that add nothing to the explanation. If a private value sits inside an area you need to show, cover it with an opaque shape and export a separate file. Reopen the file you plan to send and zoom into the covered area. Check the file name and attachment so you do not accidentally send the original capture.

A support team may need a reference number to investigate. Share it in the appropriate field of the support channel. Keep passwords, verification codes, session tokens and private invitation links out of the screenshot and out of the accompanying message.

Open the same copy your recipient will see

PNG is a good starting point for fine lines and lettering. If the sharing service shrinks the preview or converts the file, check both the preview and the download. Open it on a phone at a width similar to the one your recipient will use. If the important line can only be read by zooming repeatedly, add a tighter crop or write out the line.

For example, you could report an upload error by writing “I selected a photo, clicked Upload and saw File size limit exceeded.” Then attach a close crop that shows the file size and the error. The recipient can see both the order of your actions and what you encountered in the first message.