Clean a bug report before posting it
A useful bug report explains what failed and how to reproduce it. Raw logs and screenshots can also contain session cookies, API keys, email addresses and private URLs. Keep the original private and prepare a separate report copy.
1. Collect only what is needed
Prefer a small relevant excerpt and steps using synthetic accounts or example data. Do not publish your complete project folder or browsing history when a short example can show the issue.
2. Clean network captures and logs
Use Browser log cleaner for a HAR file and the appropriate text cleaner for pasted logs. Review which fields the tool removes. Request and response bodies may contain application-specific secrets that a generic rule does not recognize.
3. Replace identifying text consistently
Use Personal info redactor to review common identifiers and your own company, project or customer terms. Its prompt privacy mode can replace the same term consistently so a report remains understandable. All matching stays local; nothing is sent to an AI service. Check short terms carefully to avoid changing unrelated words.
4. Check files and screenshots
Folder/ZIP secret scanner can flag supported credential patterns before you share source snippets. Treat findings as leads, not a complete security audit. Cover sensitive screenshot text with opaque boxes, and look at browser tabs, address bars and notifications as well as the main window.
5. Read the final report
Open the actual exported files. Search for known private names, token prefixes and addresses. Confirm that replacements did not remove the details needed to reproduce the bug. If a real credential was already published, revoke or rotate it at its provider; editing the report cannot recall existing copies.
What to keep in mind
Pattern-based tools can miss unfamiliar secrets and flag harmless examples. Local processing protects the input from upload to this site, but you remain responsible for reviewing what you later post elsewhere.