Screenshots and GDPR: when sharing one is a data breach

A screenshot is personal data whenever something in the frame identifies a living person: a name, an email, a face, an IP address, or an account or order number that links back to someone. Sharing that screenshot to the wrong channel, a public forum, or a third party with no lawful basis is an unauthorised disclosure, which is exactly what GDPR calls a personal data breach, and no hacker has to be involved. This is a general explainer, not legal advice.

Is a screenshot personal data?

Yes, if it contains anything that identifies a living person. GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable natural person, and it gives names, identification numbers, location data and online identifiers as examples. A screenshot is just a container. What matters is what is inside the frame. If the pixels show a name, an email, a face, a phone number, or an account, order or customer ID that can be traced back to a person, the image is that person's personal data. A clear photo of an identifiable face is personal data on its own, even with no caption.

Here is how the common things caught in a screenshot map onto GDPR's own list of identifiers.

A face image is worth a line on its own. Under ICO guidance a photo of a face is ordinary personal data, but it does not automatically become biometric data. It crosses into biometric, a special category with stricter rules, only when you run specific technical processing on it, such as building a face template for automated recognition. So a screenshot of someone's face is personal data you must handle with care, and it can be more than that depending on what you do with it.

When is sharing a screenshot a data breach?

When you disclose personal data without authorisation. GDPR Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. The word people miss is unauthorised disclosure. A breach is not only a hack. Sending a screenshot that contains someone else's personal data to the wrong recipient, into a public Slack channel or forum, or to a third party you have no lawful basis or agreement to share it with, is a disclosure you were not authorised to make. Sending personal data to the wrong recipient is one of the most common breach types the ICO records.

Not every slip has to be reported, but the threshold is lower than most people assume. Under the ICO's guidance you must notify the regulator within 72 hours of becoming aware of a breach where it is likely to result in a risk to people's rights and freedoms, and you must tell the affected individuals directly where the risk is high. A screenshot of a support ticket posted publicly, with a customer's name, email and message in it, is the kind of everyday disclosure that can clear that bar. If you handle this at work, the safest habit is to treat a screenshot with someone else's data in it as something you scrub before it leaves your machine.

What GDPR expects before you share

Three plain principles cover almost every screenshot case.

• Minimise. Only capture and share the part you actually need. If the point is a chart, crop out the customer list beside it. Data minimisation is a core GDPR principle, and a tight crop is the cheapest compliance you will ever do.
• Have a lawful basis. If you are sharing someone's personal data as a business, you need a reason GDPR recognises for doing it, and the person should not be surprised by where it ends up.
• Redact properly. For anything that has to stay in the frame, remove it so it cannot be recovered before you send the image. If you want the hands-on steps, see how to hide customer data in a support screenshot and the fuller guide on how to redact a screenshot on a Mac.

Redaction only counts if the data is actually gone

This is where good intentions leak. Covering personal data is not the same as removing it, and GDPR cares about whether the data is still there. A blur or a mosaic leaves the original pixels in the file in a scrambled arrangement that can be estimated or reconstructed back, and short, structured text like an account number in a known font is the easiest thing of all to rebuild. A black box dragged over text in an editor is often a separate layer sitting on top of intact data you can select, copy or delete. In both cases the personal data never left the file, so for GDPR purposes it was never redacted. That gap is the whole subject of obfuscation versus redaction, and it is why a blur does not satisfy removed. If you want the wider view on what else a screenshot can give away, see whether it is safe to share screenshots.

A note for US readers on CCPA

The idea travels. Under California's CCPA and CPRA, personal information is anything that identifies, relates to, or could reasonably be linked to a particular consumer or household, and the statute lists real names, email addresses, account names, IP addresses and similar identifiers. So the same test holds: a screenshot showing any of that is personal information, and sharing it carelessly carries the same kind of exposure. The label changes across regimes. The habit of scrubbing before you share does not.

How ScrubShot fits

I built ScrubShot around the one rule that survives every regime above: remove the data, do not merely hide it. Its Scrub tool is real redaction. It fills each mosaic block with the average of a few pixels sampled at random from across the whole selected region, so the block pattern holds no relationship to whatever sat underneath. There is no per-block mapping to solve, so it reverses to nothing by design, and the scrub is baked straight into the image rather than parked on a removable layer. That is the difference between covered and gone.

It also closes the other GDPR gap most people never think about. The capture, scrub and share flow makes no network connections, so a screenshot with a customer's name or a client's details in it is never sent to a third-party web tool to be processed. The personal data stays on your Mac, which means you are not quietly handing it to another processor just to blur it. ScrubShot runs on macOS 14 and later, on both Apple Silicon and Intel.

FAQ

Is a screenshot personal data under GDPR?

It is if anything in the frame identifies a living person. GDPR defines personal data as any information relating to an identified or identifiable person, and it lists names, ID numbers, location data and online identifiers as examples. A screenshot showing a name, an email, a face, an IP address, or an account or order number that links back to someone is personal data. A clear photo of a face is personal data on its own.

Is a picture personal data under GDPR?

Yes, when it lets you identify someone, directly or indirectly. A photo of an identifiable person is their personal data. A face image is not automatically biometric data, though. Under ICO guidance it only becomes biometric (a special category) when you run specific technical processing on it, such as building a face template for automated recognition. Holding or sharing the image is still ordinary personal data.

When is sharing a screenshot a data breach?

GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Sending a screenshot that contains personal data to the wrong recipient, a public forum, or a third party with no lawful basis is an unauthorised disclosure, so it can be a breach with no hacker involved. If it is likely to risk people's rights, the 72-hour notification duty can apply.

What personal data is not covered by GDPR?

Truly anonymous data is out of scope, meaning data where no living person can be identified by any means reasonably likely to be used. Data about a deceased person is not covered by UK GDPR either. Purely personal or household activity is exempt, so a screenshot you keep for yourself is different from one your business shares. The moment a screenshot can be tied back to a living individual, it is in scope.

Does hiding data in a screenshot before I share it help?

Only if the data is actually removed from the file, not merely covered. A blur or a mosaic obscures pixels that are still present and can be estimated or reconstructed back, and a black box on a separate layer sits over intact data you can select or delete. For GDPR purposes the personal data is still there, so it is not truly redacted. Real redaction rewrites or removes the underlying pixels so nothing is left to recover.