Guide
One sentence carries this page: a redaction removes information and an annotation adds it, and what the recipient gets is the sum of the two. Redaction practice treats the covered region as the whole of the privacy question, because that is where the effort goes. But the arrow you drew to be helpful, the highlight you used to draw attention, and the label you typed to be clear are all published content, and they all say something about the parts you hid.
These failures are not sloppy redaction. They survive a careful one. You can cover every sensitive region in the frame, at the right size, in an opaque mode, verify the export at full zoom, and still hand over the thing you were protecting - because of something you added next to it deliberately.
Two different acts in the same picture
It is worth separating them properly, because they are usually done in the same app with the same mouse and thought of as one job called "marking up the screenshot".
Subtraction replaces pixels with something that does not depend on what was there. A solid fill is the clean case: the output is the same colour regardless of the input, so the input is gone from the file. Blur and pixelate are partial subtraction - they discard most of the samples but keep coarse structure such as word length, line count and gaps.
Addition puts new marks on top: arrows, circles, boxes with no fill, freehand strokes, typed text, numbered callouts, highlighter passes. These carry information from your head into the file. Some of it you meant to send. Some of it - which region you consider important, what you think the reader should look at, what you believe is going on - comes along whether you meant it or not.
Almost every shared screenshot contains both. The advice everywhere, including on the rest of this site, addresses only the first. The interesting failures live in the interaction.
Highlighting is not covering, and the reason is arithmetic
This is the single most common way an annotation tool gets used as though it were a redaction tool, and it is worth being precise about why it fails, because the usual phrasing - "highlighting doesn't really hide it" - sounds like a caution rather than a fact.
A highlighter is see-through by definition. That is what a highlighter is for: if it were opaque you could not read the thing you highlighted, which would make the tool pointless. So when a highlight-style stroke, a translucent shape, or a fill at reduced opacity is laid over a region, the result for each pixel is a blend: part of the overlay colour, part of the pixel that was already there. The original value is still a term in the output. It has not been replaced; it has been mixed.
Because it is still a term, it can be solved back out. If a reader knows the overlay colour and how strong the blend was, the original is recoverable by rearranging the same blend, and the practical obstacle is only how much rounding error gets amplified in the process. And a reader can usually work out both unknowns without being told, because a highlight stroke almost always overhangs the text onto a plain background - white page, grey panel, solid app chrome. Wherever the overlay sits on a region whose original colour is obvious, the blend gives up its own parameters. The overhang calibrates the attack.
Three consequences follow, and all three are worth acting on:
- Partial opacity is not a weaker version of a cover, it is a different category. The distinction is not how dark it looks. It is whether the output still depends on the input.
- A half-opacity black rectangle is less safe than a blur, even though it looks heavier and more deliberate. The blur in the editor above redraws the region from a copy scaled down by a factor of ten, so roughly ninety-nine percent of the original samples no longer exist anywhere in the file. A translucent rectangle discards nothing at all - it only makes the numbers harder to read by eye.
- You cannot tell opacity by looking. A stroke set to ninety-five percent and a stroke set to one hundred look nearly identical on screen, and only one of them is a cover. If your tool has an opacity control anywhere in its settings, the only safe assumption is that you do not know what it is currently set to.
The test that settles it needs none of this reasoning: open the file you are about to send - the exported file, not the editor's canvas - zoom to full size, and look. If you can make out what is underneath, so can the recipient, and no argument about blend parameters is needed. How to verify a photo was actually redacted covers that check in full, and it is the right check here precisely because it inspects the artefact rather than the intention.
The arrow is an index
Suppose you have done the covering properly. Nine black boxes across a banking screen, all opaque, all correctly placed. You then draw one red arrow pointing at a tenth thing - the transaction you actually want your colleague to look at - and send it.
The arrow has told the reader where to look. That is its job and it did it. But in a frame full of covers, an arrow, a circle or a callout also ranks them. It separates the box that matters from the boxes that are there for uniformity, and it converts a search problem into a lookup.
This compounds badly with what the reader already knows. Redacting for someone who already knows half the answer makes the case that a reader holding part of the picture needs far less residue than a stranger does, because confirming a guess is cheaper than reconstructing a value. An annotation is a direct contribution to that: it removes the reader's uncertainty about which covered field is the interesting one, which is often the expensive half of the problem. You covered ten things so that no single one stood out, and then you made one stand out.
Annotation also discloses something the boxes alone do not: your judgement. The set and geometry of your covers already map what you consider sensitive. Arrows and circles add what you consider important, and the two together are a fairly detailed statement about how you read the situation. In an ordinary exchange that is harmless. Where the image might end up in front of someone with an adversarial interest in your reasoning, it is not.
None of this means do not annotate. It means place the annotation with the same care as the cover:
- Point at what you want read, not at what you hid. An arrow terminating on a black box is the one placement with no upside.
- Prefer a wider mark to a precise one when the region is near covered material. Circling the row is less informative than circling the field inside it.
- Consider whether the annotation belongs in the message instead of the image. "The charge I mean is the third row" costs nothing and is not burned into a file that may travel further than the message.
- Drop numbered-callout legends that explain each box. A key mapping 1 through 5 to field names is a caption for your redactions.
Labels: the case for and the case against
Typing a word beside a cover is the annotation people are least suspicious of, and it is the one where the right answer genuinely depends on the situation rather than on a rule.
The case for labelling is that an unexplained blank is ambiguous. A reader cannot tell the difference between a field that was blanked and a field that was empty, and in anything functioning as a record - evidence, a claim, a disclosure, a document someone may act on - that ambiguity is itself a defect. A labelled cover says a value existed, a person removed it, and here is the category it belonged to. That is information the reader needs in order to treat the image honestly.
The case against is everything in the previous section. A label converts a shape into a named field. "Account number" beside a box tells a reader holding a list of account numbers exactly what to try matching, and it does so in a frame where, without the label, they would have had to guess which rectangle was which.
A workable middle: label the category, never anything that narrows the value. "Redacted" is safer than "account number", which is safer than "account number - ends in the 4400s". If the reason for labelling is to prove a removal occurred rather than to describe what was removed, the most generic label available does the whole job. And if the image is going somewhere the distinction between blank and removed does not matter, the label is pure cost.
Order of operations: cover first, annotate the export
Most people do this backwards, because annotation is the fun part and redaction is the chore. The order that works is:
- Cover everything first, in a tool that flattens, on the original capture.
- Export a flat image. This file contains no sensitive material and no layers.
- Open that export in the annotation tool and draw on it.
- Export again, flat, and verify that file at full zoom before sending.
The payoff is that the annotation app never receives an image containing the sensitive material. That matters more than it sounds, because annotation apps accumulate state: recent-file lists, autosave copies, project files, cloud sync, sometimes a share sheet that offers the original alongside the edit. Each of those is a place an uncovered frame can persist after you have stopped thinking about it. Reverse the order and you have handed the uncovered capture to the app with the longest memory in your chain.
The second payoff is about objects. Annotation tools generally keep marks as editable objects for as long as they can - that is what makes them useful. Whether the file you eventually send still contains those objects depends entirely on the tool and the format you saved to, and it is not something to assume either way. A shape sitting on top of an image as an object is not a cover: whoever opens the file can select it and move it. The check is concrete and takes ten seconds - reopen the file you are about to send and try to click the mark. If it selects, drags, or shows handles, you are looking at a layered document and the material underneath is intact.
This is also the argument against doing the covering in an annotation tool at all. A rectangle drawn with a shape tool looks exactly like a redaction and may be nothing of the kind, depending on its opacity setting and on whether the export flattened it. Two independent ways to fail, neither visible on screen.
What the editor above does and does not do
The tool on this page has three modes and three selection shapes and no annotation capability whatsoever. There is no arrow, no text, no freehand pen, no highlighter and no opacity slider. That is not a gap to apologise for - it is the point. It only subtracts, which means the two failure modes above cannot occur in it, and it makes the tool the correct first step rather than the only step. A few specifics, read from the page's own code:
Black Box is fully opaque, with no transparency anywhere. It paints a flat fill of a single near-black value across the selected region. The fill does not vary with what was underneath, and no partial-opacity setting is applied at any point in the process. This is the property a highlighter lacks, and it is why the mode exists.
Blur and Pixelate discard samples rather than blending. Blur redraws the region from a copy scaled down by a factor of ten and back up. Pixelate averages into blocks sized at a twelfth of the region's shorter side, with a floor of six pixels. Both genuinely destroy detail - which is a real difference from a translucent overlay - but both preserve coarse structure such as length, spacing and line count, which is why the warning bar appears when you select them.
Every export is a flat, freshly encoded PNG. Download writes the current canvas out as a new PNG named with a timestamp. There are no layers in it, no selectable objects and none of the tags the source file may have carried. That is exactly the kind of file to hand to a second app for annotation, and you can press the button as many times as you like in one session.
The working view is scaled; the file is not. The canvas is created at the image's true pixel size while being displayed fitted to the panel inside a box that scrolls. Text that looks illegible here is stored at full resolution and reads normally to anyone who zooms, so the preview is never evidence about the export. A tall capture can also be exported with regions that were never on your screen during the session, since Download writes the whole canvas.
Small selections are dropped silently. A rectangle under about four image pixels in either direction, or an oval under six, is discarded rather than applied, and a freehand lasso needs at least three points. A quick tap over a short value may have covered nothing, with no error to tell you.
Undo restores rather than removes. Coverage is painted destructively onto the working canvas, Undo steps back through saved pixel snapshots, and Clear redraws from the original image the page still holds. Undo genuinely puts the original pixels back, which is what you want while you work and a reason the only file that matters is the one you exported.
All of it runs on the device the picture is already on: the page reads your file in the browser, draws it into a canvas, and hands the result back as a download. There is no account and no history for the image to sit in, and the working copy exists only while the tab is open.
Common mistakes and misconceptions
Using the highlighter to hide something. The most direct version of the failure. A highlighter is built to leave the text readable; using it as a cover asks it to do the opposite of its function.
Turning down the opacity of a black box so it looks less aggressive. Aesthetics aside, this moves the mark out of the category of things that remove information. Ninety-five percent is not one hundred percent.
Assuming a mark is flat because it looks flat. Whether the file carries the shape as an object depends on the format you exported to. Reopen it and try to select the mark.
Drawing the arrow at the covered field. The one placement that has no benefit and hands over which box is the interesting one.
Annotating first and covering second. This produces an intermediate file containing the uncovered image inside the app least likely to forget it, and risks leaving a mark pointing at something you subsequently decided to hide.
Adding a numbered key that explains each redaction. A legend mapping boxes to field names is a caption describing exactly what you removed.
Restating the covered value in the accompanying message. Covering the card number in the image and then writing it in the email is the same disclosure with an extra step. The file is not the only channel.
Doing the covering inside the annotation tool because it has a rectangle. Two independent failure modes - opacity and layers - neither of which is visible on screen.
Cropping tightly to the annotated area and calling that safe. Narrowing the frame is genuinely good, but a crop is an edit to an image that already contained the material, and the wider original usually still exists somewhere.
Over-correcting to no annotation at all. An image the reader cannot interpret gets a reply asking for the original, which is worse than a well-placed arrow. The goal is a mark that points at what you want read, not the absence of marks.