A screenshot should help another person see what matters. A full desktop full of unrelated windows often does the opposite: it adds visual noise and may expose messages, filenames or account information. Start by deciding what the recipient needs to understand.
The built-in Screenshot controls and Markup tools on Mac can handle many support and explanation tasks without an extra app. Available options vary by macOS version and by the application being captured. Some protected content cannot be captured normally.
Choose the smallest useful capture
Use Shift-Command-5 to open the Screenshot controls on supported macOS versions. Select a whole screen, a window or a selected area according to the task. Shift-Command-4 offers a direct selected-area capture; Shift-Command-3 captures the screen.
For an error dialog, include the dialog and enough surrounding context to identify the app. For an alignment problem, include the relevant neighboring elements so the comparison makes sense. Cropping so tightly that the recipient cannot tell what they are looking at can be as unhelpful as capturing everything.
Before capturing, close or move unrelated private content. This is safer than trying to cover every secret after the fact. Inspect browser tabs, notifications, sidebar filenames and menu-bar information, not only the central window.
Check where the file will go
In the Screenshot options, inspect the save destination and any timer setting. A timer can help when you need to open a menu before capture. Choose a destination you can find again rather than assuming every screenshot lands on the Desktop.
Name the resulting file for its purpose, such as “Export dialog — missing format option.” A descriptive filename helps when several images are attached to the same support request. Avoid putting a customer's private identifier in the filename if it is not necessary.
If a capture appears missing, check the configured destination before taking repeated screenshots. Multiple near-identical files create confusion about which image shows the current state.
Annotate one claim at a time
Open the screenshot in Preview or use the available thumbnail editing controls. Show the Markup toolbar and add a simple arrow, shape or text label to identify the relevant control. Keep the annotation away from the information it explains.
A useful label says what to inspect: “This menu has no PDF option,” not merely “Wrong.” One or two annotations are usually enough. A dense layer of arrows can hide the original evidence and make a small problem look more complicated than it is.
Do not redraw an interface to make the problem appear clearer than it was. If you need to illustrate an expected state, keep that separate and label it as a mockup. A screenshot should remain an honest record of the captured screen.
Handle private information deliberately
A colored rectangle placed over sensitive text in an editable document is not a universal redaction method. For an ordinary image, create a sanitized copy and inspect the actual exported file. For a PDF containing selectable text, use an appropriate redaction workflow rather than assuming a visual overlay removes the underlying content.
The simplest option is often to recapture after replacing private content with a harmless test value. If that changes the behavior being investigated, explain the limitation and share only through an appropriate channel. Do not publish credentials or personal information just to prove that an error occurred.
Build a useful support example
Suppose an export menu lacks the format you expected. Capture the menu and the application's title area, then annotate the missing-choice context. In the message, state the task, what you clicked and what you expected to see. Include the app and system version separately if relevant.
The image and text should complement each other. The screenshot shows the available choices; the message explains why a choice matters. Neither needs a long history of every unrelated troubleshooting attempt.
| Capture decision | Good reason | Avoid |
|---|---|---|
| Selected area | One dialog or control is relevant | Cutting off the app or error context |
| Window | The whole app state matters | Including unrelated windows behind it |
| Full screen | The arrangement across apps is the issue | Exposing private sidebars without need |
| Timer | A menu must remain open | Guessing that the captured state matches the intended moment |
Verify the file the recipient will see
Open the saved or exported image, not just the editing window. Check that text is readable at a normal viewing size, annotations are legible and private details are absent. If the recipient needs to zoom dramatically, capture a more focused region or supply a second contextual image.
A good screenshot reduces the next person's guesswork. The final check is whether someone unfamiliar with your screen can identify the problem and the action it concerns without being distracted by everything else on the desktop.
Sources & further reading
Apple’s documentation supports the feature details. The scenarios and decision sequences above are CJVV’s editorial guidance.