Blur text in a screenshot (passwords, account numbers, keys)

I could still read a blurred six-digit code

I typed a fake OTP into a notes app, screenshotted it, and tried a moderate blur. At 100% zoom I could still name four of the six digits from the leftover shapes. A black bar on the same region left a flat slab. That is why this page starts you on the bar, not a smear.

Pixelate at a large tile size is a middle option if a solid rectangle looks too harsh in a ticket. It is still weaker than a bar. Do not use a light blur on passwords, keys, IBANs, or card digits.

Why blur fails on short secrets

A face can survive a smear because you only need “not identifiable at a glance.” A password cannot. The original pixels are still in the file, just spread. With a known font, a small alphabet, and a string that is six to nineteen characters long, that leftover shape is often enough.

Number plates have the same physics, which is why the plate tool tells you to pixelate rather than blur. Passwords, keys, and account numbers are the same class of object: high contrast, even spacing, short enough to brute-force by eye. A black bar replaces the pixels with flat colour. Nothing is left to recover.

Crop is better still when the secret sits in a corner. Pixels that are no longer in the file cannot be guessed back. Paint over what you must keep in frame; cut off what you do not.

What usually needs covering

• Passwords and recovery codes, including the line a password manager or “show password” eye left visible.
• API keys, personal access tokens, session cookies, and .env values in a terminal, editor, or browser query string.
• IBANs, account numbers, routing numbers, and the balance on a banking screen.
• Card PAN, expiry, CVV, and the last four when they sit next to a name or address.
• One-time codes from SMS, WhatsApp, or an authenticator app. They expire, but they are short enough that a light blur does not hide them.
• Salary figures, tax IDs, and employee or customer account numbers in a spreadsheet snip.

Phone numbers and email addresses belong on the same list when the screenshot is going to anyone who should not have them. The phone and email guide covers that case.

Bug reports and bank support

Two situations produce most of the leaks, and they look like “being helpful.”

A bug report wants the error. It does not need the token in the URL, the customer hostname in the stack, or the Authorization header in the dumped request. Cover those, then attach the export. The walkthrough is hide an API key before you file a bug.

Bank support wants the error code or the failed transfer. It does not need a full IBAN sitting next to your name, or a notification banner that repeated the amount. Cover the numbers, leave the error readable. See hiding a card number or banking screenshot.

OTPs are a third trap: people screenshot a WhatsApp or SMS code to send it to themselves, then the photo sits in Recents. Do not screenshot the code if you can avoid it. If the shot already exists, black-bar it before it leaves the device.

Check the export before you send it

Open the downloaded PNG at full size. A box that covered the text in a small preview can leave a character sticking out at full resolution, and a blur that looked heavy on a phone can read clearly on a monitor.

Then confirm you are attaching the export, not the original at the top of Recents. Sending the wrong file is a more common failure than a weak cover.

For redacting a screenshot in general, use the screenshot tool. For a face, use blur a face. For a licence plate, stay on the number plate page.