Redact Text in a Screenshot Before You Share It
A screenshot is not a picture of a screen. It is a copy of everything that happened to be on it — the tab title, the account chip, the notification that arrived mid-capture, and the colleague's name in the sidebar. Most leaks are in the parts nobody was looking at.
Free, no account, and the image never leaves your browser.
The screenshot captures more than the thing you wanted to show
People take screenshots to show one thing: an error message, a design detail, a stuck payment. The frame around that thing is captured without being chosen. It includes whatever the application decided to display — the signed-in account in the corner, the shared workspace name in the header, the list of open documents, the timestamp with a timezone, and the notification that popped up while the shutter was effectively open.
This is why screenshot leaks are so common and so hard to self-check. The person reviewing their own screenshot sees the error message, because that is what they were looking at when they took it. The account chip is invisible to them for the same reason it was never considered.
There is a second layer that is specific to screenshots over photographs: text is crisp. The failure modes that make blur acceptable on a photograph — soft edges, motion, noise — do not apply. Crisp small text survives a surprising amount of blurring, and it is trivially readable at full zoom. A screenshot needs a harder redaction than a photo does, not a softer one.
The checklist most people skip
Read this list against your screenshot before you draw anything. It is ordered by how often each item is missed, not by how sensitive it is.
- Account chip or avatar menu
- Top-right in nearly every web application, showing the signed-in email or full name. Missed more than any other element.
- Browser tab title
- Applications put the document name, the customer name, or the account address in the page title. It shows in the tab strip and in window lists.
- Workspace, organization, or tenant name
- In the header or a breadcrumb. It reveals the employer even when personal details are covered.
- Sidebar and document lists
- The names of other documents, customers, or colleagues you are not disclosing. Visible in the left rail and often cut off at the edge, which makes it easy to overlook.
- Notification popups
- A toast or a system notification that appeared during capture. Usually a message preview with a name and part of the text.
- Timestamps, timezone, and locale
- Correlating a timestamp with a public profile is enough to identify a person in some contexts. The clock in a menu bar includes the timezone.
- URLs and internal hostnames
- The address bar, and internal links shown in the page. A hostname like admin.internal.example.com is information about infrastructure.
- API keys and tokens in a code sample
- A screenshot of a terminal or a config file. Keys have recognizable prefixes, and detection matches several of them.
- QR codes and barcodes
- They encode data that a redaction of nearby text does nothing about. Cover them completely if they are not the subject of the screenshot.
What detection covers, and where it stops
Detection reads text in the image and matches six pattern types. For a screenshot this is a real time saver, because screenshots are exactly the crisp-text case that recognition handles well.
Found automatically
- Email addresses
- US phone numbers in common separated formats
- Social Security numbers in the separated form
- Card numbers of 13 to 19 digits that pass the Luhn checksum
- IPv4 addresses
- API keys with the sk-, AKIA, and ghp_ prefixes
Needs a box by hand
- Names, usernames, and job titles. There is no named-entity detection, so a person's name is never found automatically.
- Workspace names, document titles, and internal hostnames.
- Faces, avatars, and photographs.
- Any text that is small, low contrast, or rendered in a font the recognition pass reads poorly.
- Handwriting and annotated screenshots.
- QR codes and barcodes, which are graphics rather than text.
A repeatable pass that catches the corners
The order is deliberate: automatic first, then the frame, then the body. Working body-first is what causes corner leaks.
Open the screenshot
Drop it, paste it with Ctrl/Cmd+V, or choose a file. PNG, JPEG, and WebP up to 25 MB and 40 million pixels.
Run auto-detect once
It reports what it found, grouped by type. Treat the report as a list of candidates, not as a completion signal.
Walk the frame
Top strip: tabs, account chip, address bar. Left rail: document and people lists. Bottom strip: notifications, status bar, clock. Cover what you find before moving inward.
Cover the body content
Names, amounts, message text, and anything that identifies a customer or a colleague. Solid black by default; white only where the background is dark and a black box would look like part of the interface.
Toggle detected types to double-check
The type filter can hide a whole category of detected boxes. Turning email off and looking again is a fast way to confirm whether the remaining boxes cover everything you intended.
Export, then zoom to 100%
The download is a new PNG at the original resolution. Check each box edge at actual size — a one-pixel sliver of a character is the failure mode that thumbnails hide.
Crop first, redact second
The cheapest way to remove information from a screenshot is to not include it. If the browser chrome, the sidebar, and the taskbar are irrelevant to what you are showing, cropping them away removes a whole category of risk in one operation instead of eight.
Cropping is not always possible. Sometimes the sidebar is the context, or the error only makes sense with the header visible. When that is the case, the frame has to be redacted deliberately rather than assumed harmless.
A related habit worth building: take the screenshot twice. The first capture tells you what is in the frame. Close the notification, switch to a neutral account or a demo workspace, and capture again. A screenshot of a demo environment is fundamentally safer than a redacted screenshot of a production one, because there is no chance of missing a box.
For screenshots that must come from a real account, the reliable sequence is: cover the corners, cover the body, then review the exported file rather than the editor. The editor shows you boxes on top of an image. The exported file shows you what a recipient will actually receive, which is the only thing that matters.
Frequently asked questions
- Is blurring text in a screenshot safe?
- Usually not for small text. Screenshot text is crisp and often occupies few pixels per character, which is the case where a blur leaves enough structure to reconstruct. Use solid fill for anything that must not be read.
- Can I redact a screenshot on a phone?
- Yes. On touch screens there is a Draw/Scroll switch so a tall screenshot remains scrollable. Draw mode captures the drag as a box; Scroll mode hands panning back to the browser.
- Does the tool find names automatically?
- No. Detection matches six fixed patterns — email, phone, SSN, card number, IPv4, and API keys. Names, usernames, and job titles always need a box drawn by hand.
- What happens to the screenshot after I download it?
- Nothing is stored. The image is decoded in the tab, the edit exists only in memory, and reloading the page discards it. The download is the only file that exists.
- Does the exported PNG keep the original metadata?
- The export is drawn on a fresh canvas and encoded from pixel data, so the source file's metadata structure is not carried over. This is a property of rebuilding the image rather than editing it in place.
- Should I use black or white fill?
- Black is the default and the safest. White is useful on a dark-mode screenshot, where a black box can read as a UI element and confuse a reader about whether something was removed.