Screenshots You Send for Work: A Metadata Checklist

Most of the advice on this site, like our piece on what messaging apps do with photo metadata, is about camera photos. But the files most professionals send every day are not camera photos. They are screenshots: an invoice for the accountant, a dashboard for the client, an error message for IT, a property listing for the group chat. People assume screenshots are safe because a screenshot has no GPS tag. That is true and mostly irrelevant, because screenshots leak a different category of information, and they leak it in plain sight, inside the image itself.

What a screenshot file actually contains

On the metadata side, screenshots are cleaner than photos. macOS and Windows capture tools generally write no EXIF block, no camera serial, no GPS. What they do write is the file name and, depending on the tool, timestamps. iOS and iPadOS screenshots are the exception worth knowing about: since iOS 15 they can carry location in some contexts, and the file names encode the capture date and time to the second. "IMG_20260909_143112.png" tells the recipient exactly when you were looking at that screen, which occasionally matters more than where.

The real payload is visible in the pixels. Unlike a photo's hidden tags, everything in a screenshot is information you chose to include, or failed to exclude. The failures are the problem.

The five things to check before you hit send

1. The browser chrome and tab titles. A screenshot of one dashboard tab usually arrives with five other tab titles readable across the top. Those titles can name internal systems, client names, or personal accounts. Crop the top of the browser or use your browser's built-in full-page capture, which typically isolates the page content.

2. The notification tray and taskbar. On Windows and Android, the lower and upper edges of the screen carry message previews, calendar reminders and email subjects. A client-visible screenshot with "Meeting with Competitor X, 4pm" in the corner has ended business relationships. Full-screen capture includes all of it by default; a window-only capture (Alt+PrtScn on Windows, Cmd+Shift+4 then Space on macOS) excludes the desktop entirely and is the better habit.

3. The file name of the image itself. Photos dragged from a camera or phone keep names like DSC_0456 or the date-named pattern above. If you rename a file "final_v3_REAL_final.png" that is harmless. If your filesync prefixes your company name or the matter reference, the recipient learns your internal filing scheme for free.

4. Document edges and neighbouring content. The classic failure is a screenshot of one line in a spreadsheet that includes the row above: a different client's name, a salary, a balance. Zoom in on your own capture before sending and read everything, not just the part you meant to show. Your eye stops at the target; the reader's does not.

5. The URL and query string. Screenshots of web apps include the address bar. Many internal tools encode record IDs, customer references, even session-adjacent parameters in the URL. If the reader can reach the same system, they can sometimes reach the record.

Why photos are still the bigger risk

None of this replaces the usual checks when the file is a camera photo. A photo taken on a phone still carries EXIF unless something stripped it, which is why it is worth checking for GPS before sharing, and our metadata remover exists for exactly the case where the platform does not strip tags for you. Screenshots simply fail differently: they leak by including, not by embedding. Two disciplines, one habit: look at the actual file you are about to attach, edge to edge, before you attach it.

A one-minute pre-send routine

Capture the window, not the screen. Open the capture and read the four edges, then the file name. Blur or crop anything that names a person, an account or a system the recipient should not see. Rename the file to something neutral. That routine costs under a minute and removes nearly all of what screenshots actually leak. The metadata problem in a screenshot is not hiding in the bytes. It is sitting in the frame, waiting to be read.