Guide
One sentence carries this page: a redaction you did not perform becomes your responsibility the moment you pass the image on — and you have to discharge it without the original, without the ability to re-capture, and without knowing what the sender meant to hide.
Note what this page is not. It is not the pixel-level inspection procedure; that is a page of its own, how to verify a photo was actually redacted, and the techniques there work the same whether the file is yours or not. This page is about the position you are in when the image is somebody else’s work: what you can establish, what you can fix, what you should refuse to do, and what to say back.
Three things you do not have, and one thing you do
You do not have the original. Most verification is comparison: the redacted export against the source, this version against the last one, what the cover hides against what was there. None of that is open to you. You cannot confirm that a cover is in the right place, because you do not know where the value was. You cannot tell whether a suspiciously narrow box is snug or short. And you cannot detect the most serious class of problem at all — a value the sender never noticed, and therefore never covered, looks exactly like a value that was fine to show.
You cannot re-capture. The single strongest technique in redaction is not covering anything: it is producing a view that never contained the sensitive material, by capturing a narrower region, collapsing a panel, signing out of a profile, or exporting the one row that was needed. Every one of those requires access to the live thing. What you hold is a flat picture. Your options are strictly additive — you can cover more, and that is all.
You cannot see intent. Boxes are visible; reasoning is not. An account number left legible beside three covered ones might be deliberate, because you are supposed to work with that one. It might be an oversight. It might be a value the sender believed was harmless and that is not harmless in your hands, because you know something they do not. Nothing in the pixels distinguishes these, and guessing wrong in either direction is costly: treat a deliberate disclosure as a leak and you waste everyone’s time, treat a leak as deliberate and you republish it.
What you do have is the fork. The sender chose what to cover. You choose whether the result is read once and deleted, filed in a system, forwarded to a named person, or published. That decision changes the required standard far more than any choice the sender made about box sizes, and it is entirely yours.
Receipt is a fork, not an endpoint
The check you owe is proportional to where the image is going. Four common destinations, in ascending order of what they demand.
Read it and delete it. The lowest standard, and mostly a housekeeping problem rather than a judgement one. The risk is retention you did not intend: the file is in your downloads folder, in your messaging client’s cache, in a device backup, and possibly in a preview thumbnail that outlives the file. If the image is sensitive enough that the sender bothered to redact it, it is worth actually deleting rather than leaving it to age out.
File it somewhere. Attaching it to a ticket, pasting it into a channel, dropping it in a shared drive. The standard rises with two multipliers: how many people can reach that store, and how long it lives. Both are usually larger than they feel at the moment you paste. A support ticket may be visible to a whole queue, may be exported, and may have text pulled out of attachments for search; you generally cannot audit any of that from where you sit, so assume it rather than hoping.
Forward it to a specific person. This is the one that quietly breaks things, because the sender redacted against an audience and you are adding someone to it. Your new recipient may know things the original audience did not — the department, the account, the property, the dates — and a cover that was sufficient against a stranger can be transparent to a colleague. The audience for a forwarded image is the union of everyone who has ever seen it, and each forward widens the union without anyone re-examining the cover.
Publish it. The highest standard and the only irreversible one. Once an image is public, it can be archived, mirrored, indexed and scraped within minutes, and withdrawing your copy does not withdraw theirs. If you are publishing somebody else’s redaction, you are vouching for work you did not do and cannot fully verify. The honest options are to check it hard, to cover more yourself, or to ask for a version built from the original.
A check you can run without the original
None of this requires special tools, and it takes a few minutes. Work through it before the image moves, not after.
1. Look at the covers themselves, at full size. Ask what kind of cover it is. A flat opaque fill replaces the region outright. A blur or a pixelation keeps the coarse structure of what was underneath, which matters most for short values drawn from a small set — a date, a plate, a four-digit code, a name from a known team. If something you are being asked to rely on is softened rather than blocked out, that is worth querying with the sender rather than accepting.
2. Walk the perimeter of every cover. Partial coverage is the most common failure and the easiest to see once you are looking: the top of an ascender above the box, a descender hanging below it, the first character’s left edge outside the left edge. Zoom well past one hundred per cent to do this, and do it on the file itself rather than on a chat client’s inline preview, which is downscaled and hides exactly this.
3. Read everything that was not covered, as a stranger would. This is the step that catches real leaks, and it is hard because you are reading the image as the sender’s story rather than as evidence. Go region by region instead: window title, tab strip, address bar, breadcrumbs, timestamps, a sidebar that is half in frame, a notification that slid in during capture, a signature block, a reflection, a file path along the bottom. The margins are where redaction fails, because the sender was concentrating on the middle.
4. Ask whether what is visible recomputes what is hidden. A covered line item with a visible total and visible siblings is arithmetic, not a secret. A covered balance between two visible balances is a subtraction. A covered count that also appears as a percentage elsewhere is a division. This is a property of the document rather than of the cover, so it survives the strongest black box.
5. Check what arrived with the image. The file name, the caption, the subject line, the message above it and the thread it landed in are all part of the disclosure, and the covered name is frequently written out in plain text in one of them. If you forward the image, decide deliberately how much of that container travels with it — and rename the file, because an exported name often describes exactly what the picture is.
6. Check whether the original is in the same thread. A very ordinary sequence: someone posts a screenshot, realises, apologises, posts a redacted one. Both are now in the conversation, and everyone in it can scroll. In that situation the redacted version is doing no protective work for the existing audience at all — though it is still the right file to forward onward, because it limits the new audience. What it does not do is undo the first post, and treating it as though it had is how a leak gets quietly dropped instead of handled.
7. Ask whether an image is the right thing to pass on. Often what the next person needs is a value, a date or a sentence, and a screenshot is just the format it happened to arrive in. Quoting the relevant line in text carries no margins, no window chrome and no covered regions to second-guess, and it is easier to answer questions about. Forward the image when the picture itself is the point.
The mechanics behind the first two steps — zooming past full size, stretching contrast and brightness across a covered region, and opening the saved file rather than trusting a live preview — are set out in how to verify a photo was actually redacted. They are written for checking your own export, and they apply unchanged to somebody else’s.
What you can repair, and what repairing quietly creates
A received image is a flat picture, so you can open it in the editor above and cover more of it. That is a genuine and often correct move, particularly before forwarding to a wider audience than the sender had in mind. Three things come with it.
It is housekeeping, not remediation. Covering your copy does nothing about the copy in your inbox, the copy in the sender’s sent items, the copy anyone else in the thread received, or any preview generated along the way. If a redaction has failed on an image that has already circulated, the fix is a conversation with the sender about the distribution, not an edit you make locally.
Two versions of one image is its own hazard. If your more-heavily-covered version circulates alongside the sender’s, anyone holding both learns which regions you thought needed hiding — and if the covers do not line up exactly, the difference between the two frames narrows down where the sensitive material sits. When you tighten a received image, the safe shape is a version that covers everything the sender covered and more, never a re-drawn set of boxes in slightly different places.
You cannot go the other way. If the sender covered something you actually need, no editing recovers it, and asking is the only route. That includes the case where the cover is simply too large and has taken out context you needed to interpret the rest.
One courtesy that prevents a lot of confusion: if you alter an image before passing it on, say so, and say what you changed. Two versions in circulation with the same file name and no note is how people end up comparing them.
Do not try to recover what was covered
Two reasons, and the second is the important one.
The practical reason is that it mostly does not work in the way people imagine. An opaque fill has replaced those pixels in the file; there is nothing underneath to recover, and software that offers to restore a degraded region is generating plausible content rather than retrieving true content — which is a different thing, and dangerous in its own way if you then act on what it produced. Softened covers are a weaker case and can sometimes be narrowed down, particularly where the value has few possibilities. The whole question is worked through in can AI unblur a photo.
The better reason is that succeeding is the failure. If you work out the covered value, you are now holding the exact thing the sender decided not to give you, and you obtained it deliberately. That changes what you can honestly say about your copy, it changes your position if the material is ever disputed, and it is not undone by deciding afterwards that you will not use it. There is a legitimate version of the same curiosity: checking whether a cover is weak, in order to tell the sender. Stop at the point where you can say the cover is weak, and do not continue to the point where you can say what it hides.
If you need the value, ask for it. That request is ordinary and easily answered, and it usually turns out that the value can be sent as text without the picture at all.
Telling the sender that a redaction failed
How you report it determines whether it stays a small problem.
Reply to the sender, not to the thread. Replying to everyone turns a leak that people had not noticed into one they will now go and look at. Direct message the person who sent it.
Do not demonstrate it. Resist pasting a zoomed crop of the weak cover, and do not write out what you were able to read. Naming the region is enough: the third line of the table, the blur over the reference at the top right. A report that contains the leaked value is a second copy of the leak, in a new place, with your name on it.
Be specific about what is wrong. Vague warnings produce vague fixes. The useful shape is: which region, what kind of failure, and what you would do instead. The box over the address stops short of the postcode. The account number is blurred rather than blocked out. The total is still visible and the covered lines add up to it.
Ask for a version built from the original. A patched copy of the leaked file is worse than a fresh export from the source, because patching preserves the original’s layout and the two versions can then be compared. Where the sender can re-capture a narrower view instead of covering more, that is better still.
Say what you are doing with your copy, and do it. Deleting it, holding it until they confirm, or keeping it because it is already in a case file — any of these can be right, but the sender needs to know which, because their decision about how far to escalate depends on how many copies exist.
Lead with distribution, not with the flaw. If the image has already gone to a group, a ticket or a public post, that is the first sentence. Time matters more than diagnosis; how the cover failed can be worked out later.
If you are the one republishing it
Publishing someone else’s redacted image means adopting their judgement in front of your audience, and your audience is not the one they prepared for. Three levers are available and one is not.
You can cover more, which is cheap and usually sufficient for details the sender had no reason to think about. You can quote instead of showing, which removes the problem entirely when the picture is not itself the evidence. You can go back to the source and ask for a version prepared for publication, which is the right move whenever the image is load-bearing — senders are generally willing, and they are the only party who can re-capture. What you cannot do is narrow the frame after the fact in any way that removes information rather than covering it, because cropping a received image still leaves you working from a file that has already been flattened, and the editor on this page has no crop at all.
One more consideration specific to republishing: a picture of a redaction is itself informative. The number of covered regions, their sizes, their positions and what remains around them tell a reader about the structure of the underlying document, and in a small community that can be enough to identify which document, which account or which person it concerns, without a single covered character being read.
What the editor above can and cannot do with an image someone sent you
Read from this page’s own code, because the limits matter more when the file is not yours.
It is entirely region-based. Three modes — Black Box, Blur, Pixelate — and three selection shapes: rectangle, oval and freehand lasso. Every operation replaces the pixels inside the selection you drew. There is no crop, no resize, no rotate and no whole-image operation of any kind, so you cannot trim the margins off an image somebody sent you here; covering them is the only option this tool offers.
It cannot uncover anything. Undo reverses covers you drew in this session, one at a time, and Clear redraws the file you opened — which is the already-redacted version. Neither touches the sender’s work, because their covers are simply part of the image you loaded.
It does not analyse anything. No text recognition, no face or field detection, no warning that a cover looks weak, no check that a covered value appears somewhere else in the frame. It will not tell you whether the image you received is safe. Every check described above is yours to run by eye; the tool draws covers and nothing else.
Small drags are silently discarded. A rectangle under about four image pixels, or an oval under about six, applies nothing and says nothing. Patching a received image tends to mean small, precise covers, which is exactly where this bites.
The preview is scaled and scrolls; the export is not. Editing happens at true pixel size while the canvas is displayed scaled inside a panel capped at seventy per cent of the window height. A tall screenshot has regions below the fold that you have not looked at and that are fully present in the file you forward.
Download writes a fresh flat PNG. The export comes off the canvas as a re-encoded PNG named hideshot- followed by a timestamp, at the source image’s exact pixel dimensions, with no layers and no tags carried over from the file you opened. Rename it before you forward it, since the name travels.
Nothing you open here leaves your browser. The file is read locally, the editing happens on a canvas in the open tab, and the page keeps nothing between sessions — no localStorage, no sessionStorage, no IndexedDB, no account. That matters more than usual for a received image: looking closely at someone else’s sensitive file does not put a copy of it anywhere new.
Common mistakes and misconceptions
Treating the presence of boxes as a clearance. The boxes tell you someone thought about it once, for a different audience.
Checking after you forward rather than before. The whole value of the check is that it happens while the audience is still small.
Reading the image as the sender’s story. You will follow the point they were making and never look at the margins, which is where redaction fails.
Judging the covers in a chat preview. Inline previews are downscaled, which hides the partial covers you are trying to find.
Assuming a visible value was left visible deliberately. Sometimes true, often not, and the pixels do not distinguish the cases. Ask.
Assuming the reverse, and reporting every visible detail as a leak. Report what you can justify; the sender may need you to see some of it.
Trying to read what is under the cover. Failure teaches you nothing and success leaves you holding the thing you were not given.
Quietly patching it and forwarding it as though it were the original file. Two versions with one name is how people end up comparing them.
Re-drawing boxes in different places rather than adding to the existing ones. The difference between two versions localises what both were hiding.
Reporting the failure to the whole thread. It directs attention to a leak most readers had not noticed.
Including the value you read in your report. That is a fresh copy of the leak, sent by you.
Accepting a patched file when a clean re-export is available. Patching preserves the layout of the version that leaked.
Forgetting the file name, the caption and the thread. The container is part of the disclosure and it travels with the forward.
Believing that a later redacted version cancels an earlier unredacted post. It limits the next audience; it does nothing about the one that already saw it.