A one-person redaction workflow has exactly one place to go wrong: the edit. You open the picture, you cover the thing, you check your work, you send it. Every technique page on this site is written for that situation, and the interesting questions are all about pixels — is a blur reversible, does the black box cover the descender on the last character, did the crop actually remove anything.
The moment a second person is involved, almost none of that is where the risk lives. The photograph now travels. Somebody takes it, somebody else edits it, possibly a third person approves it and a fourth publishes it, and at every seam there is a chance to hand over a version that still shows everything. The characteristic team failure is not a badly drawn box. It is a perfectly redacted final file sitting downstream of a chat thread where the untouched original is still scrollable, or two colleagues covering slightly different parts of the same frame and releasing both.
This page is about the seams. It covers who should redact and when, what a written standard needs to contain, how to review someone else’s redaction without re-circulating the thing you are trying to contain, and the specific coordination mistakes that produce leaks nobody individually made.
Related: how to verify a photo was actually redacted.
Guide
Start from an uncomfortable observation. In a team, the person who is best at image editing is very often not the person who took the photo, and the natural instinct is therefore to send the raw file to them and let them handle it. That instinct is the single largest source of multi-person redaction failures, and everything below follows from refusing it.
Rule one: the original travels as little as possible
Redaction is not a formatting favour you ask a colleague for. It is a reduction in who can see something, and a reduction cannot be performed by first showing it to one more person. If you send an untouched screenshot of a customer’s account to a designer so they can black out the account number, the account number has already been disclosed to the designer, to whatever service carried the message, and to every future reader of that thread. The redacted file that comes back is tidy, but the exposure happened before it existed.
So the rule is: whoever holds the original redacts it, and only the redacted version moves. This is sometimes inconvenient, because it means the least skilled editor in the chain does the edit. That is an acceptable trade. Covering a rectangle is a skill anyone acquires in about ninety seconds; unsending a message is a skill nobody has.
The corollary matters just as much. If someone sends you an unredacted image, the correct response is not to quietly redact it and carry on. Tell them, ask them to delete their copy from the thread if the tool allows it, and treat the original as disclosed for planning purposes. Silently cleaning up other people’s leaks means the same person leaks again next week, and the team never learns that the seam exists.
Decide who redacts at the moment of capture
Ambiguity about responsibility is what produces the “I assumed you’d handle it” failure, and it is astonishingly common in exactly the situations that matter — an incident channel, a support escalation, a rushed compliance request. Two people each believe the other is the redactor. The image goes out clean of nothing.
The fix is a one-line convention that assigns the job by position rather than by skill: the person who creates the file is the person who redacts it, before it is attached to anything. Position is unambiguous in a way that skill and seniority are not. Nobody has to negotiate, nobody has to guess, and the rule survives contact with a busy Tuesday.
Where that genuinely cannot work — a photo arrives from outside the organisation already unredacted, say — name a single owner explicitly, in writing, in the thread. “I’m redacting this, nobody else attach it anywhere” costs one sentence and removes the ambiguity entirely.
Write the standard down, and keep it short
A standard that lives in one person’s head is not a standard; it is a habit that will be applied inconsistently the moment anyone else does the work. But a twelve-page policy will not be read either. In practice a workable shared standard fits on a single screen and answers five questions.
- What counts as sensitive here? Enumerate it for your actual material, not in the abstract. “Account numbers, customer names, internal ticket URLs, anything in the notification bar, anything on a whiteboard in the background” is useful. “Personal information” is not — it delegates the judgement back to the individual, which is the thing you were trying to stop.
- Which method? Pick one and make it the default rather than leaving it to taste. An opaque box is the conservative choice for text and numbers, because it does not attempt to preserve any of the underlying structure. Reserve blur and pixelation for cases where someone has a positive reason to want the shape of the content to remain visible, and make that a deliberate exception rather than a shrug.
- How much margin? Cover generously and consistently. If one person covers the digits exactly and another covers the whole field including the label, you have two different-looking outputs and, if both ever circulate, a comparison that tells a reader precisely where the boundary of the sensitive content is.
- What happens to the original? Kept, and where? Deleted, and by whom? This is the question teams skip, and it is the one that determines whether the redaction means anything in six months. A redacted export sitting next to its untouched source in a shared folder protects nobody.
- Who checks, and against what? See below. If the answer is “nobody”, say so honestly rather than implying a review that does not happen.
Write those five answers in a pinned message or a short page and point at it whenever someone new joins the rotation. The value is not in the prose. It is in removing per-image judgement calls from people who are hurrying.
Reviewing someone else’s redaction without undoing it
A second pair of eyes genuinely helps, because the person who drew the box has been staring at the image and has stopped seeing the rest of the frame. But a naive review defeats itself: if the reviewer asks for the original so they can compare, the original has just travelled again, and the review has cost you the thing the redaction bought.
The resolution is that a good review almost never needs the original. What a reviewer is checking is whether the released file still discloses something, and that is a question about the released file alone. Hand over the redacted export and have the reviewer work it like a stranger would:
- Zoom to full resolution and pan the entire frame — edges, corners, the status bar, reflections, anything on a wall or screen in the background.
- Check the covered regions at maximum zoom for partially covered characters, visible ascenders and descenders, and any residual texture where an effect was applied too gently.
- Read the parts that were deliberately left visible and ask what they identify in combination. Individually harmless details triangulate.
- Check the things attached to the image rather than inside it: the filename, the caption that will accompany it, the alt text, the name of the folder it sits in.
Only if the reviewer suspects something specific should the original be consulted, and then by the original holder, on their own machine, rather than by sending it. How to verify a photo was actually redacted works through that check in detail, and it is the right thing to hand a new reviewer instead of training them yourself.
The consistency problem is a real leak, not a tidiness issue
This is the part that surprises people. Suppose two colleagues independently redact the same photograph — one for a support ticket, one for a slide — and cover slightly different regions because there was no shared standard. Each file on its own looks fine. Released together, they are worse than either, because everything visible in one is available to a reader of the other, and the sensitive content is whatever both chose to cover. The set discloses more than any member of it.
Inconsistency between people is simply the most likely way a team ends up with such a set, which is why the margin question above earns its place in a five-line standard. The general case, including what it takes to make multiple versions safe rather than merely different, is worked through in two redacted versions of the same photo can leak each other. The short version for team purposes: if a second version has to exist, derive it from the first by covering more, never by starting again from the original and making different choices.
How a browser-based editor fits a shared workflow
Worth being precise about what the tool on this page does, because it determines which parts of the workflow it can carry. The editor covers regions by painting them destructively onto the canvas, so the covered pixels are replaced rather than hidden beneath a layer, and Download PNG exports the canvas as a freshly encoded file named hideshot-<timestamp>.png. Undo steps back through exact snapshots of earlier canvas states, and Clear redraws from the original image the page still holds, so an editor can back out a mistake without re-opening the source file. All of that happens on the device the image is already on.
For a team that matters in two practical ways. First, it means the capture-side rule is cheap to follow: the person holding the original does not need editing software installed, a licence, or an account, so “you redact it before you send it” is not an unreasonable thing to ask of a colleague who does not edit images for a living. Second, because each export is a new PNG and you can export repeatedly within a session, the additive workflow above is easy — cover the shared baseline, export, then cover more and export again for the narrower audience.
What it does not do is manage your process. It cannot tell you who was supposed to redact, it cannot reach a copy already sitting in a thread, and it has no opinion about which folder the original ends up in. Those are the parts that need the written line and the named owner.
Common mistakes and misconceptions
“I’ll send it to the person who’s good at Photoshop.” The most common and the most costly. Sending the original in order to get it redacted is a disclosure that the redaction cannot undo. Skill at the edit is worth far less than keeping the file still.
Treating a private channel as not-a-disclosure. An internal thread, a DM and a shared drive folder all widen the set of people who can see the file, often permanently and often to people who join the channel later. “Internal” is a statement about intent, not about who can read the scrollback.
Reviewing by comparison. Asking for the original so you can diff it against the redaction is a review method that costs more than it finds. Review the released file on its own terms.
Leaving the original next to the export. Two files in one folder, one named with the word “final”, is how the wrong one gets attached six months later by somebody who was not part of the original conversation.
Assuming shared judgement. Two careful people will still disagree about whether a first name, a room number or a partial timestamp is sensitive. That disagreement is invisible until both outputs exist, at which point it is a leak. Enumerate the list.
Making the standard a document nobody reads. A five-line pinned message that gets followed beats a thorough policy that gets skimmed once. Optimise for the version that survives a deadline.
Redacting at the end instead of the start. If redaction is the last step before publishing, the unredacted file has already passed through drafting, review and approval, and exists in all of those places. Moving the redaction to the moment of capture is the single highest-leverage change most teams can make.