Everybody who has pasted a screenshot into a support ticket, a forum thread or a group chat has at some point sent something that nobody in that thread needed. An address in the window title. A customer name in the sidebar behind the thing you were pointing at. A licence key two lines below the error message. A colleague’s full name in a notification that happened to be on screen.
It is not carelessness. It is that a screenshot captures everything and you were looking at one thing. The eye goes to the part you meant to show, and the other four hundred readable words on the screen are simply not seen by the person taking the picture, right up until they are seen by everybody else.
The usual advice is to check carefully before sending. That advice has been given for twenty years and the leaks keep happening, which is a reasonable sign that the advice is the problem.
Cover everything, then take back what can stay
The tool below inverts the workflow. It finds every region in the picture that looks like a line of text and covers all of them, then hands you the job of clicking back the parts that should remain readable.
That direction is the entire design argument and it is worth being explicit about why. A tool that tries to guess which text is sensitive has to be right every time, and the one it gets wrong is the one that costs you. A tool that covers everything is wrong constantly, in a way you can see, in a direction that is safe. You end up doing the same amount of work either way, but the failure mode of forgetting to uncover something is an unhelpful screenshot, and the failure mode of forgetting to cover something is an incident.
The detector weighs about 2.1 MB. It reads the picture in this browser tab, it does not read the text, and it has no opinion about which line matters. Nothing is uploaded and there is nowhere for it to be uploaded to.
Screenshot redactor
Before a screenshot goes into a support ticket, a forum post or a chat, it usually carries something that nobody in that thread needs: an address in the header, a customer name in the sidebar, a key in the terminal. This finds every field that looks like text and covers all of it, then lets you click back the parts that can stay. The detector weighs about 2.1 MB and the runtime it needs another 3.5 MB, both fetched only after you ask for them. Your screenshot is read in this browser tab, never uploaded, and there is nowhere for it to be uploaded to.
Blurring and pixelation can be undone. Both keep a smeared copy of the original in the file, and text set in a known typeface can be recovered from that copy by someone who cares enough to try. Only the filled bar deletes the pixels, which is why it is the setting this tool starts on. The picture you download is drawn fresh from scratch, so a covered field is not hidden under a layer, it is gone.
or press Enter to pick one. PNG, JPEG or WebP.
Sample screenshot, drawn in this browser.
A flat rectangle of one colour. Nothing of what was there survives it, in the picture on screen or in the file you save.
The outlines belong to the page, not to the picture. They are how you click a field, and they are never drawn into the file.
Click a box to leave that field readable, click it again to cover it. The boxes are reachable one after another with the tab key and switch with Enter or the space bar. Drag across the picture to add a box of your own, for a face, a logo or a map, anything that is not text.
covered left readable drawn by you
| What happened | Value |
|---|
What this deliberately cannot do. It finds text, not secrets. Whether a field it found is sensitive is a judgement it never makes and never could, which is exactly why it covers everything and leaves the taking back to you. It was trained on Latin script, so it misses unusual typefaces, very small text and text sitting on a busy background, and a missed field is covered by nothing at all: check the picture before you send it. It does not touch what is written inside the file rather than drawn in it, so the camera model, the location and the editing history in the metadata stay where they are, and for those you want the EXIF viewer. And pixelation is not deletion, which the warning above says in more detail because it is the thing people get wrong.
Why it covers everything first. A tool that guesses which line is a password and which is a heading will one day guess wrong about the one line that mattered, and nobody notices a field that was never marked. Turning it around costs a few clicks and changes what a mistake looks like: the worst case is a screenshot with too much blacked out, which is embarrassing rather than expensive. The detector runs at up to 1280 pixels on the long edge, which is enough for the text in a normal screenshot and keeps one pass under a few seconds on a processor without graphics acceleration. Pictures larger than 2400 pixels on the long edge are scaled to that before anything is drawn, so that what you see, what you click and what you download are one and the same picture. Comparable tools exist. The mechanism here is that the picture stays in the tab: the only thing that crosses the network is the model, in the other direction, after a click.
There is a second reason the covering step has to be fast, and it is about when people do it. A screenshot is almost always taken in the middle of something else: you are debugging, you are answering somebody, you are three quarters of the way through a task and the screenshot is a means to an end. Any redaction step that takes a minute competes with the thing you were actually doing, and it loses.
So the measure of a tool like this is not how thorough it can be. It is how thorough it is when somebody is in a hurry and slightly annoyed. Covering everything by default is the design that survives that test, because the careless path and the safe path are the same path.
It works before the model arrives
One decision in the tool is worth copying into anything similar. You can draw boxes and download a covered picture without loading the model at all.
The detector is a convenience, not a dependency. Somebody on a slow connection, or on a device that will not carry the weights, or who simply wants one field covered and knows exactly where it is, should not be made to download several megabytes first. Drag across the picture, get a box, download the result.
That also covers the cases the detector structurally cannot: a face, a logo, a map showing where somebody lives, a chart whose shape gives away a figure. None of those are text and none of them will ever be found by a text detector, so a manual box is not a fallback here, it is a first class part of the tool.
Blurring and pixelation can be undone
This is the part of the article that matters most, and it is why the tool starts on a filled bar rather than on the softer looking options.
A blurred or pixelated region is not empty. It is a lossy but deterministic transformation of the original pixels, which means the original is still in there in compressed form. If an attacker knows the typeface, the font size and the background, and they usually do because the rest of the screenshot tells them, then recovering the text becomes a search problem rather than a guessing problem: render every candidate string, apply the same pixelation, and see which one matches.
This is not theoretical. Depix, published in 2020, does exactly that lookup for pixelated text. Bishop Fox released Unredacter in 2022, which rebuilds text from pixelated images and was widely reported at the time. There is academic work behind both, and a separate line of attack for video that exploits camera movement: the mosaic grid stays fixed while the camera does not, so many slightly offset versions of the same block reveal more than any single one. The security researchers who published that video work end their write up by recommending an opaque, single coloured box instead, which is precisely what this tool defaults to.
The honest boundary: this does not mean every blur is recoverable. It means recovery is possible under conditions that are common, that you cannot check from the outside, and that you have no reason to bet against. If the information matters, do not obscure it. Remove it.
The picture is redrawn, not covered over
A related mistake is subtler and catches people who did use a solid bar. If a tool draws a black rectangle as a layer over an image and then exports, whether the underlying pixels survive depends entirely on how the export works. In a PDF or an SVG or a layered document, an overlaid rectangle is an object sitting on top of content that is still present in the file, and removing it is a matter of deleting one element.
There is a long history of documents released with redactions that could be undone by selecting the text underneath or dragging the black box aside. It is the same category of error as blurring: something was hidden from view rather than deleted.
So the tool redraws. The output starts from a clean copy of the picture, the covered regions are painted into the pixels themselves, and the outlines you click are elements on the page that never touch the canvas. What you download is a flat PNG in which the covered fields are not underneath anything, because they are not there.
Finding text without reading it
The detector is a segmentation model rather than a recogniser. It returns a probability map the same size as the picture, bright where it believes text is present, and that is all it returns. It never produces characters.
That was a deliberate choice and it saved 14 MB. The obvious next step would be to add a recognition model, read each field and flag the ones that look like an email address or a card number. The recognition model available for this job has a character set of digits and lowercase letters only: no at sign, no full stop, no plus. It could not identify an email address as an email address if it tried, and a tool that claimed to spot sensitive fields while being structurally incapable of recognising the most common one would be worse than no tool.
So the pipeline stops at the map. Regions are found by threshold and a flood fill over the map, turned into rectangles, given a few pixels of air, and the smallest specks are discarded. The order of those two last steps matters more than it looks: adding the air before the size filter would inflate every speck of noise past the minimum and the filter would catch nothing.
Why the outlines are not in the picture
While you are working, each found field carries a coloured outline: one style for covered, another for left readable, another for boxes you drew yourself. Those outlines are elements on the page, positioned over the canvas, and they are never painted into it.
The reason is a small thing that would otherwise be a recurring annoyance. If the outlines were drawn into the picture, the downloaded file would carry them, and you would have to remember to switch them off before exporting. Somebody would forget, once, and send a support ticket a screenshot decorated with blue rectangles.
Keeping the working view and the output separate is the same instinct as redrawing rather than overlaying, applied to the other direction. What you see while working is allowed to be richer than what you get. What you get must contain nothing you did not ask for and must be missing everything you asked to remove.
What it deliberately cannot do
It finds text, not secrets. Whether a field it found is sensitive is a judgement it never makes and never could, which is exactly why it covers everything and leaves the taking back to you.
It was trained on Latin script, so it misses unusual typefaces, very small text and text sitting on a busy background. A missed field is covered by nothing at all, so the last check is still yours: look at the picture before you send it, with the outlines on, and see whether anything readable is left that should not be.
It does not touch the file’s metadata. A screenshot usually carries little, but a photograph of a screen carries a great deal, including where it was taken, and that is a separate job with a separate tool. And it cannot help with what is outside the frame of the picture: the filename, the thread you are posting into, the message you type alongside it.
A workflow rather than a tool
The useful habit this encodes is not really about screenshots. It is about defaulting to closed and opening deliberately, which is the same principle behind a firewall rule, a permission model or a role in WordPress: start from nothing allowed and grant what is needed, because the mistakes then fail in a direction you can survive.
Applied here it means capturing the window rather than the whole screen where you can, keeping a clean separation between what a tool may reach and what it may not, covering first and revealing second, and treating a solid bar as the only redaction rather than as the ugly option. None of that requires this tool. The tool just makes the covering step fast enough that you actually do it, which is usually the difference between a policy people agree with and a policy people follow.
Comparable tools exist, including ones built into operating systems, and several of them are good. Most of them default to a blur, because a blur looks tidier in a screenshot of the screenshot. That is a real reason and it is the wrong trade, and knowing why is worth more than the tool.
