Guide
One sentence carries this page: a report about someone else’s exposed data needs two differently redacted copies — a precise one for the people who can close the hole, and a stripped one for everybody else — and the usual failure is sending one image to both.
Why this is not the same job as redacting your own screenshot
When the screenshot is yours, the redaction is a negotiation with one recipient about one thing you own. When it is a capture of somebody else’s exposed records, three things change at once, and each of them changes what you cover.
You are not the data subject. The people in the spreadsheet cannot tell you which of their fields they mind about, and you do not get to decide on their behalf that a date of birth is less serious than an address. The default moves from “cover what I would rather not share” to “cover everything that identifies a person, and justify each exception”.
You are not the responsible party either. Somebody else has to fix this, and they can only fix what they can find. Your redaction either hands them a locatable, measurable problem or it hands them a vague complaint they will close. That is a competence requirement, not a courtesy.
Holding the material is itself a risk. From the moment you take the capture, you are storing personal data you were never authorised to store. Every extra copy — the screenshots folder, the recycle bin, a sync client, a chat you pasted it into — is a second place it can leak from, and this time you are the one leaking it. The custody question that applies to any original applies more sharply here.
There is a related but different situation worth separating out: being handed an already-redacted image by someone else and deciding whether to pass it on. The checks there are about the file you were given rather than about data you discovered, and they are worked through in receiving a redacted image: what to do before you forward it. This page is about the earlier moment, when nobody has redacted anything yet and the exposure is still open.
Two copies, not one
Decide who an image is for before you draw a single box, because the two audiences want opposite things.
The fix-it copy goes to exactly one destination: the organisation responsible, through its security or privacy contact if it publishes one and its support channel if it does not; or the platform hosting the content; or, if those routes are genuinely unreachable or refuse to act, whatever authority supervises them. It is a private, one-to-one channel, and it needs to be specific enough to act on.
The everyone-else copy covers every other destination: a public post, a group chat, a thread, a curious colleague, a write-up six months later. It needs to carry no locator and no record content at all.
Those requirements are in direct conflict, which is why one image cannot serve both. If you have prepared only one, it is almost certainly wrong for one of the two audiences — either too vague to be actionable, or a second publication of the same data with decoration.
And the second copy is optional. The honest reasons to make a public version are narrow: the private channel has failed over a reasonable period, or affected people need warning and nobody else is warning them. Proving that you found it is not one of them. Most of the time the right public artefact is a sentence with no picture attached.
The fix-it copy: leave the shape, cover the contents
Work field by field with the question “does the person fixing this need to see the value, or only that the value is there?”
Leave the locator visible. The URL, the path, the bucket or container name, the ticket or record number, the search that produced the page. A report without one is a rumour. If the locator itself contains a personal identifier, split it: keep the host and path in the image and put the identifying parameter in the text of your message rather than burned into a picture that will be forwarded internally.
Leave the structure visible. Column headers, field labels, the visible row count, the page layout, the export button that suggests the whole table is downloadable. “Column F is Home address, roughly 2,400 rows, no sign-in required” is the actionable fact. The 2,400 addresses are not.
Leave one partial value, at most. Enough to show the data is real and personal rather than test fixtures: a format, a masked string, the first two characters of a field. There is a ladder from safest to most revealing — category, field name, format, partial value, full value — and for a report you stop at format or a short partial. One row is a sample; twelve rows is a disclosure.
Leave your own access method visible or state it. Whether you were signed in, whether you clicked anything, what you typed, and when you looked. This is the part of the report that establishes you did not go digging, and it is usually better written in words than shown.
Cover every complete personal record. Names paired with addresses, dates of birth, government identifiers, account and card numbers, health details, immigration status, anything that identifies a specific living person. On a table that means the body of the table goes dark and the headers stay.
Cover everyone who is incidental. An exposed list has a hundred rows and your report needs none of them intact. The temptation to leave “just a couple” visible for credibility is the single most common way these reports turn into their own incident.
Cover your own session. Your account name in the profile menu, your email, your other tabs, your bookmarks bar, your desktop behind the window. You are about to send this to strangers at an organisation that has just had a bad day.
Over-redacting this copy is a real failure rather than excessive caution, and there is a concrete reason why. Where European data-protection law applies, Article 33 of the GDPR requires a controller to notify the competent supervisory authority of a personal data breach “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, and requires that the notification “describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned”. A clock may start when somebody reads your message, and what they then owe is a category and a count. An image with every header blacked out does not help them produce either. Whether that provision binds the organisation you are writing to is not your call, and none of this is legal advice — but the practical conclusion is the same under any regime: give them the shape of the problem and keep the contents.
The public copy: lose the locator and the fingerprint
Assume a public copy will be re-shared by people who did not read your caption, and that at least one reader will try to reproduce your finding. The standards for posting a screenshot publicly in general are covered in redact a screenshot before posting to Reddit; what follows is what changes when the data in the frame belongs to people who are not in the conversation.
No locator of any kind. No address bar, no path, no bucket name, no distinctive page title, no tab title, no breadcrumb trail. This is the clean inversion: the locator is mandatory in the private copy and disqualifying in the public one, and it is why reusing the same file for both is not a shortcut but a mistake.
No unique strings. A rare surname, an unusual company name in a footer, a verbatim error message, a reference-number format, a product-specific label. Each one is a searchable handle, and the search leads back to a live exposure.
No row-level data, including partials. The partial value that was proof in the private copy becomes a seed in public. A postcode next to a first name, four digits of an account, a street without a number — all of these are enough to confirm a guess someone else already has.
No visual fingerprint of the source. A distinctive colour scheme, a logo silhouette, a sidebar layout and a particular column order identify a product between them even with every name covered. If naming the product is the point, write the name and show far less of the picture.
Watch what the boxes themselves say. Twelve rectangles in a neat row publish that there were twelve fields, and their widths publish roughly how long each value was. Usually harmless; occasionally it is the whole finding.
And the timing rule that outranks every box: publish nothing while the exposure is still open. A heavily redacted picture of an unlocked door is an advertisement that one exists, and a reader with more patience than you will find it.
What this editor can and cannot do for a report
Worth knowing exactly, because a report is the wrong place to discover a limitation.
It covers regions you draw, and nothing is automatic. There is no detection of faces, text or fields. A table with four hundred visible rows is four hundred rows of manual work, which is a strong argument for re-capturing a narrower frame instead of redacting a wide one.
Black Box is the only mode to use here. It replaces the pixels inside your selection with flat #111111, leaving nothing to recover. Blur is a fixed factor-of-ten downsample of the selection scaled back up; Pixelate replaces each block with a single sampled pixel, the block size being the shorter side of your selection divided by twelve with a floor of six pixels. Both deliberately keep coarse structure, which is exactly the help a reader needs when the hidden string has a known format — and exposed records are almost entirely known formats.
It cannot write on the image. The editor contains no text-drawing calls, so you cannot stamp a box with “personal data” or put a reference number on the capture. Treat that as a routing rule: the explanation, the locator parameter you kept out of the frame, and the count all belong in the body of your message.
It cannot crop, resize or rotate. The canvas is created at the source image’s exact pixel dimensions and nothing in the code changes them, so the export matches what you captured. A narrower frame has to come from a narrower capture.
Small covers fail silently. A rectangle drag under about four image pixels, or an oval under six, is thrown away with no message, and a lasso needs at least three sampled points before it applies. On a dense table that is an easy miss. Look at the finished image deliberately before you attach it.
One file at a time, and no memory. The file input takes a single file and the drop zone reads only the first file dropped, so dragging in a folder opens exactly one with no error. Loading the next image resizes the canvas and resets the undo history with no prompt, so download each finished PNG first. Nothing carries between files except the mode and shape you selected.
Nothing leaves the browser. There is no fetch, XMLHttpRequest or WebSocket anywhere in the editor and no browser storage of any kind; the image stays in the tab in front of you and the download is written from the canvas on your own machine. For material you had no right to hold in the first place, that is the relevant property: there is no copy sitting on a service for anyone to account for later, and no second location for it to leak from a second time.
Your clipboard still holds the original. If you pasted the capture in with Ctrl+V, nothing in the editor writes back to the clipboard — there is no clipboard-write code at all — so the unredacted image is still what a paste produces. Attach the downloaded PNG. Do not paste into the report.
Then delete the original. The untouched image is retained in the page only while the tab is open, and closing the tab discards it; the copies that matter are the ones on your disk. Empty the screenshots folder and the recycle bin, and check whether that folder syncs anywhere.
Common mistakes and misconceptions
“I will blur it and post it so it gets fixed faster.” Public pressure is an escalation, not an opening move, and a blurred public copy of a live exposure is a lead rather than a disclosure.
“I redacted it, so I am not holding personal data.” You are holding the original until you delete it, and so are the folder, the bin and the sync client.
“Covering the names is enough.” A row with the name covered but address, date of birth and employer left visible identifies a person about as reliably as the name did.
“The URL is harmless, it is already public.” It is public, which means reachable by everyone who sees your image. That is fine in a private report and disqualifying anywhere else.
“They will know which record I mean.” They have thousands. Vagueness is the most common reason a well-intentioned report is closed with no action taken.
“I should send the whole thing as proof.” Send a locator and a shape. If the recipient needs more, they can look at their own system, which is the one place the data is supposed to be.
“It is fine, I only sent it to one person.” One private channel is the plan. One private channel plus a group chat plus a quoted post is a different plan that you did not mean to adopt.
“I found it by accident, so anything I do next is fine.” How you found it matters to your position; what you do afterwards is a separate decision with its own consequences for people who never got a say in any of it.
“I will keep a copy in case they deny it.” Understandable, and it is a decision to make deliberately rather than by default: keep the smallest redacted version that evidences the claim, not the raw capture, and know where you are keeping it.