Guide
One sentence carries this page: name the class of information and the reason for every region you covered, never the content, and never in finer detail than the reader's job actually requires.
A covered region is an ambiguous object
Think about what a black rectangle communicates on its own. It confirms that something was in that place. It shows roughly where that something sat in the layout, which can be informative all by itself — a box over the top-right corner of an application window is probably an account menu, a box across a table column is probably a field repeated down every row. And it shows how much space the content occupied, which is a weak but real signal.
That is the entire message. Three facts, two of them approximate. Everything else the reader believes about the hidden content is something they supplied themselves.
What they supply depends on their position. A colleague assumes you covered the obvious things and moves on. A stranger with no stake assumes nothing much and reads around the box. A counterparty — a landlord, a customer in dispute, an opposing party, anyone whose interests run against yours — assumes the box is where the inconvenient part went, because that is the cheap assumption and because it occasionally turns out to be right. None of those readers can distinguish a card number from a sentence you did not want quoted. The picture does not carry the difference, and no amount of care in drawing the box will make it.
This is why a redacted image is a weaker artefact than people expect. You have removed a risk and, in the same motion, introduced an ambiguity. Handling the ambiguity is a separate job from handling the risk, and it is done with words rather than pixels.
What silence costs you
Sending a redacted image with no explanation has three distinct costs, and they bite in different situations.
The round trip. The reader cannot tell whether what they need is behind a box or simply absent from the frame, so they ask. Now there is a second message, often a second capture, and a conversation about the image instead of about the thing the image was meant to settle.
The silent misreading. Worse than asking is not asking. A reader who assumes the covered region was irrelevant proceeds on a premise you never gave them, and you find out weeks later when a decision was made on an incomplete picture. Nobody in that sequence did anything wrong, which is exactly what makes it hard to catch.
The credibility hit. If you have any stake in how the image is read, the boxes become an argument against you. The reader is not obliged to believe that you covered only private details, and the more the image favours your position, the more natural it is to wonder what the rectangles cost them. This is the cost that no improvement in redaction technique can address, because it is not about whether the cover works. It is about whether the choice of what to cover was made in good faith, and that is unknowable from the file.
In formal disputes the stakes of that doubt are higher and the conventions are stricter: covering parts of an image that will be submitted as evidence is a narrower problem, handled separately in redacting photos used as evidence in a legal case, and the rules that bind any particular proceeding are a question for whoever is running it rather than something a general guide can answer.
Describe the class, not the value
The useful way to think about an explanation is as a ladder of specificity, with five rungs:
1. The category. Personal details of a third party. Payment information. Internal system identifiers.
2. The field. The account holder's name. The card number. The session token in the address bar.
3. The shape. A sixteen-digit number. A four-letter first name. A sum in the low five figures.
4. A partial value. A card ending 4412. A name beginning with M.
5. The value. The thing you covered.
Rung one is almost always safe. Rung two is usually safe, specific enough to be believed, and the right default. Rungs three and beyond are where explanations start undoing the work: once the reader knows the length, the format or a fragment, the covered value stops being unknown and becomes a guessing problem with a small answer set, and the arithmetic of how small is covered in detail in partial redaction: how much can you safely leave visible.
The pressure to slide down the ladder is social rather than technical. Rung two can feel evasive, so people reach for a detail to prove they are being straight — a length, an initial, a rough figure — and that detail is precisely the thing the box existed to remove. Notice the impulse and stop one rung higher than feels comfortable. If the reader genuinely needs a value, the answer is to give them that value deliberately through an appropriate channel, not to leak an approximation of it inside a reassurance.
A note you can paste
Adapt the specifics, keep the structure. Count, then class and reason per region, then the sentence about what is not covered.
"There are four covered areas in this screenshot. Three of them are the customer's name, email address and phone number, in the header and down the right-hand side — removed because they are not relevant to the fault. The fourth is the session identifier in the address bar. Nothing to do with the error itself, the timestamps or the reference number has been covered, and no part of the image has been cropped or otherwise edited."
Four sentences, and the last one is doing most of the work. A reader's real question is almost never what is behind the box; it is did you remove anything that bears on this. Answering that directly, in a clause, closes the loop without describing a single value. The note about cropping is worth keeping too, because a crop removes evidence without leaving a mark, and saying plainly that you did not crop is a claim you can make in one breath and that the reader cannot otherwise verify.
For a set of images, state the rule once for the whole set rather than annotating each picture. It is shorter, it is easier to apply consistently, and it gives a reader far less material to cross-reference between pictures.
When the explanation is the disclosure
There are cases where even a class-level description is the leak, and they are recognisable in advance.
The category's existence is the news. "I have removed the second complainant's name" discloses that there is a second complainant. "I have removed the medication name" discloses that there is a prescription. In both, the class is the sensitive fact and no amount of vagueness about the value helps. Go coarser: third-party personal details have been removed.
The reader can resolve the class themselves. Someone who knows the system can often map a field plus a position to exactly one value. Tell an administrator that the box in the sidebar is a user identifier and they may be able to work out which user from the row order, the record count or the layout. A class-level note is only safe against a reader who cannot do that resolution.
Several notes join up. Explanations accumulate across a thread or a bundle the way the images do. Each note is innocuous; the set of them describes the structure of your data, which fields exist, and which ones you consider sensitive. Writing one rule for a set rather than an inventory per image limits this directly.
The general-purpose escape hatch is to describe the policy instead of the instance: state that all personal details of people other than the parties to the conversation have been removed throughout, and give no inventory at all. That sentence is almost always safe to write, it answers the good-faith question, and it contains nothing to work with.
Over-redaction is the other half of the same problem
The failure that gets far less attention than under-redaction is covering things the reader needed. It is common because drawing a box is cheap and caution feels free: a reference number looks like an identifier, a timestamp looks like metadata, an error code looks technical, so all three disappear and the screenshot now proves nothing.
Three symptoms worth checking for before you send. The image no longer shows the thing you are claiming it shows. The reader cannot connect it to a record, a ticket or a moment in time, because every handle has been covered. Or the boxes outnumber the visible content so heavily that the picture reads as a document someone did not want you to see.
The test is to redact against the reader's task rather than against a list of scary-looking data types. Ask what the recipient has to be able to do with this image — find the account, confirm the sequence of events, see what the interface looked like — and treat anything required for that as presumptively staying, to be removed only if there is a real reason. When something they would plausibly need does have to go, that is exactly the case for saying so in the note and offering the alternative route: the value typed out separately, a narrower re-capture, a reference they can look up at their end.
Over-redaction also has a credibility cost of its own, and it is sharper than the one from silence. A page covered in rectangles invites the reader to assume the worst about every one of them, so caution applied indiscriminately buys you less trust than caution applied precisely and explained in a sentence.
When they ask for the unredacted version
Treat the request as ambiguous, because it usually is, and figure out which of three things is being asked before answering.
If they are missing a particular value, give them that value on its own and say which box it came from. A typed account number in a message is a far smaller disclosure than the original frame that contained it along with everything else on that screen.
If they are missing context, a different capture usually beats the original: a tighter shot of the panel, a wider shot that shows where it sits, or a reproduction of the same view with test data. Re-capturing is underrated as a response here, because it answers the need without ever putting the original into circulation.
If they are asking because they do not believe the redaction was honest, understand that no file solves this. Sending the original would answer the doubt by abandoning the reason for the redaction, and it is also the irreversible move — once it is in a mailbox, a ticket attachment store, a search index and the overnight backup, plenty of systems will not let you take it back out. What addresses the doubt is the class-and-reason note, a willingness to be specific about what you did not cover, and in serious matters an offer to have the unredacted version reviewed by someone neutral rather than by the person you are in dispute with.
What the editor above does and does not do
The tool on this page is region-based and nothing more. Three modes — Black Box, Blur and Pixelate — across three selection shapes: rectangle, oval and freehand lasso. Each operation replaces the pixels inside the region you drew. Black Box fills it with a solid near-black; Blur downsamples the region heavily and scales it back up; Pixelate replaces blocks with a single sampled colour. Undo steps back one cover at a time and Clear restores the untouched image. Download PNG writes the current canvas out as hideshot-<timestamp>.png, re-encoded from scratch rather than copied from the source file. All of it happens in the browser on your own machine; nothing is sent anywhere, which also means there is no sharing link, no stored copy and no second party to this transaction.
Two limits matter specifically for this page. There is no text, arrow, caption or label tool, so the explanation cannot be written onto the image here even if you wanted it there — it belongs in the message, the ticket comment or the document that carries the picture. And there is no crop, resize or rotate of any kind, so the export keeps the source image's exact pixel dimensions. That second limit is quietly useful: a reader comparing your export against a later capture can see that the frame was not narrowed, which makes the no-cropping claim in your note easy to stand behind.
Common mistakes and misconceptions
"The image speaks for itself." A redacted image is the one kind of image that cannot. It is a document with holes in it, and the holes are the part the reader will think hardest about.
"Explaining it looks defensive." One flat sentence naming classes and reasons reads as competence. Saying nothing and then answering questions one at a time over three messages is what reads as defensive.
"I will describe it precisely so they know I am being honest." This is the single most common way an explanation undoes a redaction. Precision about the value is not honesty; it is disclosure. Be precise about the field and the reason, vague about the content.
"Mentioning the category is harmless." Usually, but not when the category's existence is the secret, and not when a reader who knows the system can resolve a field and a position down to one value.
"More boxes is the safe direction." Covering what the reader needed forces a second round trip, and a wall of rectangles makes every single one of them look worse than it is.
"They asked for the original, so they are entitled to the original." Sometimes they are, and that is a question about your obligations rather than about redaction. Either way the original is the irreversible option, so exhaust the substitutes — a typed value, a fresh narrower capture, a neutral reviewer — before you reach for it.
"I will put the explanation in the filename or the caption on the picture." Both travel further and are harder to correct than text in a message, and a filename in particular gets read by systems and people you were not writing for.
"One note per image is the thorough approach." For a bundle it is the leaky approach. A set of per-image inventories can be laid side by side to map your fields; one rule stated once for the whole set cannot.