How to Scrub Sensitive Data from Logs and JSON Before Sharing.

The moment you paste a log file, API response, or error dump into a Jira ticket, Slack channel, or GitHub issue, you’re potentially sharing more than you think. Emails, authentication tokens, internal IP addresses, phone numbers, user IDs — all sitting in plain text, buried in nested JSON or buried in stack traces. It happens every day, and most people only realise afterwards.

What you’re probably leaking without realising

Sensitive data hides in places you wouldn’t expect:

• JWT tokens in Authorization headers — they look like eyJhbGciOi... and can be decoded in seconds to reveal user claims and expiry
• API keys in query strings and headers — sk_live_..., AKIA..., xoxb-... — any of these in a shared log is a credential leak
• Email addresses in user objects, error messages, and audit logs
• Internal IP addresses in network logs — 10.x.x.x, 192.168.x.x, 172.16.x.x — they reveal your internal network topology
• UUIDs that map to real user records in your database
• Phone numbers in international format — +44..., +1... — sitting in contact objects or SMS logs
• Long hex strings that are actually session IDs, refresh tokens, or file paths containing real usernames

The problem isn’t that one of these is hard to spot. It’s that a production error dump can contain dozens of them, nested across multiple objects, and you’re trying to share it quickly because something is broken.

Why manual redaction fails

You open the log, search for @, and redact the five email addresses you find. You miss the sixth one buried three levels deep in a nested metadata.contact_info object. You search for token-looking strings and catch the Authorization header, but miss the refresh token in the response body. You redact the email but leave the user_id that maps directly to it in your database.

Manual redaction fails because:

• You’re in a hurry — production is down and you just need help
• Real logs have deeply nested structures where the same type of value appears at different levels
• Stack traces reference file paths with real usernames — /home/jsmith/app/src/handler.py
• You find the obvious values but miss the non-obvious ones that still map to real data

How the Privacy Scrubber works

The Privacy Scrubber runs entirely in your browser. Nothing is sent to a server — paste your text, it processes it locally, and gives you a cleaned version to copy.

Here’s what it does:

1. Auto-detects JSON when the input can be parsed as JSON, and processes it structurally — it walks the object tree and replaces sensitive values while keeping keys and structure intact
2. Falls back to text mode for CSV, XML, raw logs, and any other format — it scans for patterns and replaces matches inline
3. Masks common sensitive patterns:
   • Email addresses
   • Phone numbers (international and US formats)
   • IP addresses (IPv4 and IPv6)
   • JWT tokens (eyJ...)
   • API keys and tokens (long alphanumeric strings matching common formats)
   • UUIDs
   • Long hex strings that look like session IDs or secrets
4. Labels what it replaced — output shows [REDACTED-EMAIL], [REDACTED-TOKEN], [REDACTED-IP] etc, so you can see what was caught

JSON vs text mode — what’s different

JSON mode preserves structure and validity. Values are replaced but keys and nesting remain intact. The output is still valid JSON you can paste into a ticket, and a developer can still understand the shape of the response without seeing the actual data.

Text mode replaces matches inline wherever they appear. The structure of your log or CSV is preserved as-is, but sensitive values are swapped for redaction labels. This is better for:

• Multi-line log entries with mixed text and structured data
• CSV exports where you want the columns intact
• XML with inline values
• Stack traces with file paths and usernames

The tool auto-detects which mode to use, but you can tell from the output — if you see structured JSON with [REDACTED-*] values, it was in JSON mode. If you see inline replacements in free text, it was in text mode.

When the scrubbed output is safe to share

The scrubber catches common patterns — emails, tokens, IPs, UUIDs, phone numbers, and secret-looking strings. But it can’t know your domain. Before pasting the output, scan for:

• Internal project codenames — the tool doesn’t know that “Project Sundance” is a confidential internal name
• Customer IDs that aren’t UUIDs — a customer_id: 847291 field won’t be caught because it looks like a normal integer
• File paths with real usernames — /home/jsmith/ or /Users/sarah.chen/ in stack traces
• Error messages that reference real people — “Error processing payment for John Smith” won’t be flagged because the tool doesn’t know John Smith is a customer

The scrubber is a strong first pass. Add your own domain knowledge on top of it before sharing.

Real-world scenarios

Bug report in Jira: You paste the full API response, scrub it, and share the structure without the data. The developer can see the response shape, the error code, and the nesting — without seeing real user emails or tokens.

Slack message during an incident: Instead of screenshotting a log (which is hard to search and impossible to copy-paste), paste the text, scrub it, and share the clean version. Your colleagues get searchable text, and you don’t leak credentials into a chat that gets archived.

GitHub issue for a third-party library: You hit a bug in an API client and want to paste the request and response. Scrub first — the maintainer doesn’t need your real API key to reproduce the issue, and once it’s in a public issue, it’s indexed by search engines.

Onboarding a vendor or contractor: You need to share a sample data export so they can build an integration. Paste it, scrub it, and share the shape — column headers, field names, nesting structure — without the actual customer records.

Scrub before you share — every time

The Privacy Scrubber takes about five seconds to use. Paste, click, copy, share. It’s faster than manual find-and-replace, it catches the nested fields you’d miss, and it never sends anything to a server.

Bookmark it. The next time production is down and you need to paste a log into a ticket, you’ll be glad you did.