How to Mask PII in Logs, JSON, and HAR Before Sharing

If a file is detailed enough to solve a bug, it is usually detailed enough to leak something you did not mean to share.

Before you paste a stack trace into an AI prompt or attach a HAR file to a vendor ticket, strip out the parts that identify people, sessions, or internal systems. The goal is not to delete all context. The goal is to keep the debugging clues while removing values the other side never needed.

Start with the six categories that cause most avoidable leaks

When raw logs travel through chat, tickets, and docs, these are the values that slip through first.

• Email addresses and login identifiers
• Phone numbers inside support or order flows
• Authorization headers and bearer tokens
• API keys, cookies, and session IDs
• Korean resident or business registration number patterns
• Internal URLs and private IP addresses

That is why a plain search-and-replace is rarely enough. One file can mix structured JSON, copied headers, and loose log lines in the same payload.

Pick the output style by destination, not by habit

The safest redaction format depends on who reads the file next.

• AI prompt: readable tokens such as [EMAIL_01] preserve structure without exposing the original value.
• External share: stronger markers such as [REDACTED_AUTH_01] make it harder to confuse placeholders with live credentials.
• Internal reversible workflow: stable tokens plus a restore map let a team collaborate on masked text and later reconstruct the original on a trusted machine.

The last option is useful when several teammates need to look at the same issue. It is also the one that needs the most discipline, because the restore map is effectively a secret.

Review the diff before you trust the export

Pattern-based masking is fast, but it is not magic.

A solid workflow shows exactly what changed, lets you disable specific rule groups, and keeps the scan local so you are not uploading the unmasked file just to protect it afterward.

Pay extra attention when:

• your logs contain custom field names
• your JSON includes free-text notes from users or agents
• the HAR file contains internal hostnames buried in nested objects

If the masked result still lets the reader reproduce the issue, you kept enough context. If it also hides identifiers, tokens, and internal paths, you probably removed the right things.

A small example shows the tradeoff better than a policy doc

Original:

[email protected]
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.demo.signature
cookie=sessionid=abc123xyz987
url=https://grafana.internal/team/app
ip=192.168.10.24

AI-safe copy:

customer_email=[EMAIL_01]
Authorization: [AUTH_01]
cookie=[SECRET_01]
url=[INTERNAL_01]
ip=[INTERNAL_02]

You still know which field caused the issue, which credential slot was present, and where the request was heading. You just do not reveal the live values.

A browser-only workflow is usually enough

For routine support and debugging handoffs, the practical sequence is short.

1. Load a .log, .txt, .json, or .har file, or paste the raw text.
2. Scan locally and inspect the highlighted diff.
3. Export one of three versions: AI-safe, external-share, or internal reversible.

If you want that exact flow without uploading the source file, PII Masker in Konviny Tools already handles local scanning, rule toggles, and export profiles in the browser.

Raw logs move fast across prompts, tickets, and chat threads. A short masking step before sharing is cheaper than explaining later why a token or internal host escaped.