Guide
How to redact screenshots before a bug report
A bug report is useful because it shows the real screen. That is also why it leaks. The address bar, the customer name in the corner, and the token sitting in a query string are not the bug. Cover them before you attach the file.
Last updated
Should you edit the only copy of the screenshot?
No. Duplicate the screenshot first. Redact the copy and keep the original in your downloads folder or camera roll. The editor exports a new PNG and does not replace the file you dropped in. If a box lands in the wrong place, you can start again without reproducing the bug.
Take the screenshot, then duplicate it before you draw anything. The original stays in your downloads folder or camera roll. The copy is what you redact and attach. If a box lands in the wrong place, you still have the unedited shot and you do not have to reproduce the bug just to get the picture back.
hideimage.com edits in the browser and exports a new PNG. It does not replace the file you dropped in. Paste with Ctrl+V or ⌘V, or drop the copy onto the editor. When you export, open that PNG and read it the way a stranger on the other end of the ticket will read it. Do not trust the preview in the editor alone if you were moving fast.
What does a support screenshot usually expose?
A support screenshot usually leaks the URL, the tab title, other bookmarks, and a notification, not only the password field you noticed. DevTools add headers, cookies, and user objects. Chat screenshots add other people’s names in the sidebar. None of that is required to explain a broken button.
People crop the obvious password field and miss the rest. A browser screenshot often includes the full URL. Query parameters carry session ids, email addresses, reset tokens, and internal customer ids. The tab title repeats the same name. The bookmark bar shows other internal tools. A notification slides in from Slack or a calendar while you are capturing the bug.
Developer tools are worse. The Network panel shows Authorization headers, cookie names, and response bodies. The Console prints user objects. The Application panel lists storage keys that include an email. A React or Vue overlay shows component names tied to a real account. If the bug is visual, you rarely need any of that text in the attachment.
Chat and email screenshots have a second problem: other people. A sidebar of channel names, a customer thread above the message you meant to share, an avatar, a phone number in a signature, and the address of a colleague who was only cc’d. Those are not required to explain a broken button.
Should secrets in a bug report be blurred or blacked out?
Black them out. Blur is the wrong cover for a token, a password, a card number, or a government id, because a light blur can leave letter shapes. Draw one box per secret, with a little padding, and leave the layout that shows the bug. A ticket that is one solid black rectangle does not help the person fixing it.
Blur is a comfortable look. It is the wrong tool for a token, a password, a card number, or a government id. A light blur can leave letter shapes, and a determined person with the file can sometimes guess short strings. Pixelate has the same weakness when the blocks are small and the text is large. For anything that must not be readable, switch to Black Box and paint the whole string, including a little padding so a descender or the edge of a character does not stick out.
Draw one box per secret rather than one giant box over the whole window. A ticket that is a solid black rectangle does not help the person fixing the bug. Cover the URL’s query string and leave the path if the path is what reproduces the issue. Cover the name in the account menu and leave the broken layout. Cover the bearer token in the header list and leave the status code and the endpoint path.
- Full URL if it contains a token, email, or internal id. If only the query string is sensitive, cover that part and leave the host and path.
- Authorization headers, cookies, and any console line that prints a user, a session, or a key.
- Names, emails, phone numbers, and avatars that belong to customers or coworkers.
- Notification banners, the bookmark bar, and open tabs that name other projects.
- File paths that include a home directory or a username, such as /Users/jane or C:\Users\jane.
How much of the screenshot should stay visible?
Keep the broken control, the generic error text, the wrong spacing, and enough chrome to show which product you were in. Black out the customer email inside an error and leave the error code. Cover a username in a file path and leave the function name if that is the useful part. Say in the ticket what you removed.
Redaction fails in the other direction when the screenshot no longer shows the problem. Keep the control that is broken, the error text that is generic, the spacing that is wrong, and the browser chrome that explains which product you were in. If the error message itself contains a customer email, black out the email and leave the error code. If a stack trace includes a file path with a username, cover the path and leave the function name if that is the useful part.
Write one sentence in the ticket that says what you removed. “URL query redacted; the path is /billing/invoices and the button does not submit.” That sentence is more useful than an unredacted shot, and it tells the reader the black boxes were intentional. Do not paste the secret into the ticket body after you removed it from the image. People do this with tokens. The image is clean and the comment is not.
What should you check before you attach the file?
Scroll the exported PNG and read the corners, the tab title, and every sharp string. If you can still pronounce a name, an email, or a key, it is not done. Confirm the attachment is the redacted PNG. Treat a public issue, a forum, and a shared drive as permanent. Internal chat is not a vault either.
Scroll the exported PNG, do not glance. Read the corners. Read the tab title. Read any text that is still sharp. If you can still pronounce a name, an email, or a key, it is not done. Check that you exported the redacted PNG and not the original from the screenshot tool. Operating systems happily attach the first file with a similar name.
If the report will be public, treat it as public forever. A GitHub issue, a forum post, and a shared drive link all outlive the ticket. Internal Slack is not a vault either. The same pass applies: black box for secrets, blur only for context you would not mind a coworker squinting at, and a second look at the file you are about to drop in.
The editor on this site is the same one as the homepage. Open it, paste the screenshot, choose Black Box for the secrets and Blur only where a soft cover is enough, then export. Nothing in that flow uploads the image for editing. You still decide what leaves your machine, which is the part no tool can do for you.
Questions about this
The usual questions are whether the screenshot has to be uploaded to be redacted, whether blur is acceptable for a token, and how much of the window you are allowed to leave. It does not have to be uploaded. Tokens get a black box. Leave the part that shows the bug.
Do I have to upload a bug-report screenshot to redact it?
No. Paste or drop it on hideimage.com and the canvas edit stays in your browser. Export a PNG when you are done. You still choose which file to attach to the ticket.
Can I blur a token instead of blacking it out?
Prefer a black box. A light blur leaves letter shapes, and short secrets are worth guessing. Cover the query string or the header value, and leave the path or status code if that is what the reader needs.
What if the error message itself contains an email?
Black out the email and leave the error code or the generic sentence. Say in the ticket what you removed. Do not paste the email into the comment after you removed it from the image.
Where should you go next?
Apply the cover in the same local editor this guide describes. Paste a screenshot on the homepage, or open a related note if the leak is a different kind. These links are the next step. They are not separate tools that upload the file.