Guide
One sentence carries this page: a bundle discloses the union of what every image in it leaves visible, so the thing you have to redact is the field across the set, not the image in front of you.
The union rule, and why it is unforgiving
Take six captures of the same order screen for a support ticket. The customer's name, the internal order URL and an operator username appear in all six. You cover them in five. The sixth has them in plain text because its layout put them somewhere your eye had stopped looking.
The recipient now has the name, the URL and the username. Not a blurred hint of them — the values, exactly as they were rendered. Coverage does not average out across a set. There is no partial credit for the five captures you did properly, because the reader only needs to see a value once and the set is delivered all at once. Five sixths of a redaction is zero.
Worse, the five correct covers actively help. On their own, a visible username in a screenshot is a detail a reader might skim past without registering. A username that is blacked out in five images and legible in the sixth is advertised: the boxes tell the reader that this specific field was judged sensitive by the person who sent it, and they show precisely where in the layout to look for it. The careful work turns into a finding aid for the one mistake.
The same arithmetic, applied to two redacted versions of a single photograph rather than to several different captures, is worked through in two redacted versions of the same photo can leak each other. The bundle case is the same rule with more surfaces and a much better chance of inconsistency, because each capture was taken at a different moment, often of a different screen state.
The same value almost never looks the same twice
If every capture were pixel-identical, this would be easy: cover the same rectangle six times and stop. Real bundles are not like that, because you took each capture to show something different. The same value therefore shows up in different renderings, and your eye learns to recognise the rendering rather than the value.
The appearances that get missed, in rough order of how often they do:
The truncated one. A list row shows jbarnett@exampl… with an ellipsis, so it does not read as an email address. Combined with the full address visible in a detail panel two captures later, or guessable from a visible full name, the truncation is not protection.
The address bar and the tab title. A record identifier that you carefully covered inside the page body is sitting in the URL of every capture that included browser chrome, and often in the tab title and the window title too. These are the single most common asymmetric leak in a screenshot bundle, because you stop seeing browser chrome within about ten minutes of starting work.
The notification or toast. A banner that appeared in one capture and not the others, quoting the record, the sender or the subject line in full.
The search field. You found the record by typing something into a search box. In the capture where that box is still populated, your query is the value — frequently a name or an account number — and it is in a place you never think of as content.
The sidebar, the recents list and the autocomplete dropdown. Peripheral panels change between captures. A recently-viewed list can name four other records, none of which are anybody's business.
The other layout. One capture came from a phone, or from a narrower window, and the wrap put the value on its own line where your rectangle from the desktop captures does not reach it.
The email copy. Bundles often mix application screenshots with a capture of the notification email for the same event. The email restates the record in prose, with a signature block and a recipient list that the application screen never showed.
Work from a field list, not from the images
The fix is to invert the loop. Instead of walking the images and asking what to cover in each, walk the fields and ask where each one appears. Six passes over six files sounds slower than six passes over one file each; it is the only order of operations that can catch an asymmetry, and in practice it is quick, because on each pass you are looking for exactly one thing.
1. Fix the set before you redact anything. Decide which captures are going, including the one you can already feel yourself adding later to answer the obvious follow-up question. A capture that arrives after the review is a capture that was never reviewed.
2. Write one line per distinct value, not per appearance. Customer name. Account identifier. Internal case number. Operator username. Host name in the URL. The clock. The colleague names in the chat sidebar. This list is usually shorter than you expect — most bundles have six to twelve distinct sensitive values, repeated many times.
3. Decide one treatment per field, with a reason. Cover everywhere, leave visible everywhere, or — rarely — split deliberately, because the reader genuinely needs the order number to locate the record but has no business with the name attached to it. A split treatment is fine when it is a decision. It is a leak when it is an accident, and the only difference between those two is that you wrote it down.
4. Record where each field appears, by capture number. “Order ID: 1, 2, 3, 6 in the list; 4 in the tab title; 5 in the URL only.” Building this index is where you discover the appearances you would otherwise have missed, which is most of the value of the exercise.
5. Then open the first image. Work it with the field list beside you, not from memory.
6. Review by field, across all the exports. For each line on your list, open all six finished files and look for that one value. Reviewing file by file at the end feels like the same job and is not: a per-file review asks “does this image look clean”, which your eye answers yes to as soon as it sees familiar black rectangles.
That procedure sits on top of, and does not replace, a proper sweep of each individual capture — the periphery, the reflections, the status bar, the things nobody puts on a field list because they are not fields. That single-image discipline is the subject of finding everything that needs redacting before you start, and a bundle needs it once per image before the cross-image pass begins.
What this editor carries between images, and what it does not
Worth knowing precisely, because the gaps are where bundle mistakes live.
It is one image at a time, by design. The file input on this page accepts a single file, and the drop zone reads only the first file of whatever you drop on it. Drag a folder of six captures onto it and exactly one opens, with no error and no queue behind it. If you expected a batch, the silence looks like success.
Loading the next capture discards the current one. Opening a new image resizes the canvas to the new file's dimensions, draws it, and resets the undo history to that image's untouched state — immediately, with no prompt and nothing to go back to. Download the finished PNG before you load the next capture, every time. The Clear button behaves the same way within one image: it repaints the retained original over your work with no confirmation.
Nothing is remembered between files. The editor keeps no browser storage of any kind, and contains no network call — no fetch, no XMLHttpRequest, no WebSocket — so there is no history, no project and no record of what you covered in capture one while you are working on capture two. Consistency across a bundle has to live in your field list, outside this tool.
Mode and shape do carry. Your choice of Black Box, Blur or Pixelate and of rectangle, oval or lasso stays selected when you load the next image. That is the one kind of cross-image consistency you get for free, and it is worth not disturbing mid-bundle.
Box positions do not carry. There is no snapping, no numeric coordinates, no way to copy a cover from the last image. Every rectangle is drawn by hand, so two captures of the same screen get two slightly different boxes over the same string. Usually harmless; it matters when the pair of boxes bounds the same value from two directions and lets a reader infer its length.
Small covers are discarded silently. A rectangle drag under about four image pixels, or an oval under six, is thrown away with no message at all, and a lasso needs at least three sampled points before it applies. One cover that quietly failed to land, in one capture out of six, is the entire leak. Look at each image after you finish it, not only while you are drawing.
Exports are named by clock, not by source. Each download arrives as hideshot-<timestamp>.png, taken from the moment you saved it. The source filename is not carried through. Six exports are six timestamps in save order and nothing more, so rename each one the moment it lands, while you still know which capture it was. Renaming later from thumbnails is how two images in a bundle swap identities — and a bundle read in the wrong order tells a different story than the one you meant to tell.
What only leaks once there are two
Different crops of the same screen. A tight capture of a dialog and a wide capture of the whole window are the same screen at two zoom levels. A value covered in one and present in the other is the union rule in its simplest form.
Totals against line items. If one capture shows a summary figure and the others show five of the six rows that make it up, the sixth row is arithmetic rather than a disclosure. Covering a number does not remove it when the set still contains everything needed to recompute it.
Shared chrome as a ruler. Identical fixed elements across captures — a menu bar, a column header, a logo of known size — let a reader scale and align two images precisely, then carry a measurement from the image where a string is visible onto the image where it is covered.
Sequence and gaps. Clocks and scroll positions put your captures in order and show where you did not capture. A jump from 10:02 to 10:31 is a visible hole, and a reader who cares will ask about it.
The capture of your own desktop. A screenshot that includes a file dialog, a download bar or a folder window exposes the filenames of everything else in that folder — including the captures you decided not to send and the unredacted originals you kept.
Common mistakes and misconceptions
“I redacted all six screenshots.” Files are not the unit. Fields are. Counting files is what produces the five-out-of-six result.
“More context is more helpful.” Each additional capture adds a whole frame of periphery, a different window state and another chance at asymmetry. Send the fewest images that answer the question, not everything you took while investigating.
“This one is just the error message.” A dialog capture also contains whatever was behind the dialog, and a modal usually sits in the middle of the most populated screen in the application.
“They are the same screen, so the same boxes apply.” Same screen, different state. The sidebar changed, a toast appeared, the search box is populated, one capture came from a phone.
“I will check them all at the end.” Checking at the end is right. Checking them one file at a time at the end is what fails, because a per-file look asks whether the image looks clean rather than whether a specific value is absent from the whole set.
“The order does not matter.” The order is an argument. It also decides which capture a reader treats as authoritative when two of them disagree.
“I can send the rest tomorrow.” A second batch is a second production. Boxes drawn freehand a day later will not match the first set, and the two batches together release whatever either one left visible.
“Renaming is cosmetic.” Timestamped exports are indistinguishable at a glance, and the one thing worse than sending an unredacted capture is sending it while believing it is a different file.