Redact PII before sharing logs

Before a log goes into a ticket or to a vendor, find the personal data — emails, phone numbers, names — and redact it. Detection and redaction run locally, so the raw log never leaves your machine.

Open this example in PII Detector & Redactor

Open the tool, then paste the sample input below. Everything runs locally in your browser.

Open this example in PII Detector & Redactor →

The problem

Support and debugging often means sharing a log, but production logs are full of personal data: customer emails, phone numbers, IDs. Sharing them raw is a privacy and compliance risk. You need to scan the log and replace the sensitive values before it leaves your machine.

Sample input

Raw log
2026-06-14 ERROR checkout failed for jane.doe@example.com (phone 555-271-3344) order A-1001

Expected output

Redacted
2026-06-14 ERROR checkout failed for [REDACTED_EMAIL] (phone [REDACTED_PHONE]) order A-1001

The email and phone number are replaced with typed placeholders, while the non-sensitive context (timestamp, error, order id) is preserved so the log is still useful.

How to do it

  1. Paste the log text.
  2. Run PII detection.
  3. Review what was matched, such as emails and phone numbers.
  4. Redact the matches.
  5. Copy the redacted log to share.

Common mistakes

  • Sharing the log before redacting because it "looked clean".
  • Redacting emails but missing phone numbers, tokens, or names.
  • Over-redacting useful context like timestamps and error codes.
  • Assuming structured fields are safe when free-text messages still contain PII.
  • Forgetting that the same value can appear many times in one file.

Related tools

Related guides

FAQ

What counts as PII in a log?

Personal data such as email addresses, phone numbers, names, and customer identifiers. Anything that can identify a person should be redacted before sharing.

Does the log get uploaded to detect PII?

No. Detection and redaction run entirely in your browser, so the raw log never leaves your machine.

Will redaction keep the log useful?

Yes. Sensitive values are replaced with typed placeholders while timestamps, error codes, and structure are preserved, so the log still helps debugging.

Can it catch PII inside free-text messages?

Yes. Detection scans the whole text, not just structured fields, so personal data embedded in a message is matched too.

What if the same email appears many times?

Every occurrence is matched and redacted, so a repeated value is replaced consistently throughout the log.

PII detection and redaction run locally in your browser. Your log is never uploaded.

Explore more security and debugging tools

Redact PII, scan for secrets, decode tokens and sanitize captures — grouped in one place.

View the security & debugging toolkit →

Practical example and expected result

Before a log goes into a ticket or to a vendor, find the personal data - emails, phone numbers, names - and redact it. Detection and redaction run locally, so the raw log never leaves your machine. In practice, this is most useful when you need a quick, repeatable check on a HAR capture before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is 2026-06-14 ERROR checkout failed for jane.doe@example.com (phone 555-271-3344) order A-1001. The expected result should resemble 2026-06-14 ERROR checkout failed for [REDACTED_EMAIL] (phone [REDACTED_PHONE]) order A-1001, with the same important values preserved.

Troubleshooting checklist

  • Confirm you copied the complete HAR capture and not only a partial line or truncated preview.
  • Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
  • Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
  • Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps