How to redact emails, phones & card data from json & api logs locally
- Step 1Capture the log you need to share — Save the request/response dump, the webhook payload, or the error log to a
.jsonor.txtfile. CSV and Markdown logs work too, and a spreadsheet-style log (.xlsx/.xls/.ods) is accepted with its first sheet flattened to a JSON array. The scrubber inspects value *content*, so nested keys and structure don't matter. - Step 2Drop the log onto the scrubber — Drag the file into the drop area above (it accepts
.csv,.json,.txt,.mdplus.xlsx/.xls/.ods). There's no paste-text box — the tool works on an uploaded file, so save your clipboard log to a file first. Processing is fully in-browser; the log is never transmitted by this tool. - Step 3Run the scrubber — Press Run Email/Phone Scrubber. No settings — the six detectors run in a fixed order (email, IBAN, card, SSN, NI, then phone last). The card and IBAN passes apply their checksums, so a request ID or trace token that isn't a valid card/IBAN stays exactly as logged.
- Step 4Review the sanitised log — The cleaned log appears in a scrollable panel with a metrics line: items redacted, bytes in/out, run time. Confirm the JSON still looks structurally intact and that the values you need for debugging (status codes, error messages, timestamps, IDs) survived while the PII became
[REDACTED_*]. - Step 5Copy or download the clean log — Use Copy to paste the sanitised text directly into a bug tracker or ticket, or Download to attach it as a file (named with a
-scrubbedsuffix). For a spreadsheet input the download keeps the.xlsxname but the content is the scrubbed JSON array of the first sheet. - Step 6Eyeball anything regex can't shape-match — Tokens, bearer secrets, internal IDs, usernames, and free-text addresses are not detected — the scrubber only matches the six shaped categories. Before pasting into a public tracker, scan the sanitised log for API keys/secrets (rotate them if exposed) and any identifier the regex shapes don't cover; redact those by hand.
Log fields the scrubber catches — and the ones it doesn't
PII in logs is shaped (caught) or unstructured/secret (not caught). The detectors handle the former; tokens, IDs, and free text need a manual pass.
| Log content | Example | Caught? | Tag / note |
|---|---|---|---|
| Email in request body | "email":"sue@example.com" | Yes | [REDACTED_EMAIL] |
| Phone in payload | "phone":"+44 20 7946 0958" | Yes | [REDACTED_PHONE] |
| Card in payment debug line | "pan":"4242 4242 4242 4242" | Yes (Luhn-valid) | [REDACTED_CARD] |
| Request / trace ID | "req":"1234567890123456" | No | Fails Luhn — kept |
| Bearer token / API key | "auth":"Bearer sk_live_…" | No | No secret detector — redact + rotate |
| Username in a message | "login as jsmith" | No | No username/free-text detector |
Inputs, output, and tier limits
A free-tier tool; only the file-size ceiling changes by plan. Verbose log dumps can exceed the free limit and need trimming first.
| Aspect | Behaviour |
|---|---|
| Accepted input | .json, .txt, .md, .csv as text; .xlsx/.xls/.ods (first sheet flattened to a JSON array first) |
| Options | None — no toggles, no custom mask. All six detectors run every time |
| Output | Sanitised text in the original format with [REDACTED_*] tags; Copy to clipboard or download as <name>-scrubbed.<ext> |
| Multiple files | Drop area accepts several, but only the first is scrubbed per run |
| Where it runs | 100% in your browser tab; a server-safe API path returns { output, redactedCount, counts } |
| File-size limit | Free 10 MB · Pro 100 MB · Pro + Media 500 MB · Developer 2 GB (oversize text throws an exceeds the … limit error) |
Cookbook
Log fragments showing what stays parseable and what survives a sanitise. All values below are fabricated examples.
Request log stays valid JSON
A captured request body with an email and phone. Tags drop inside the quotes, so the engineer can still paste the result into a JSON viewer.
Input (request.json):
{
"event": "signup",
"user": { "email": "sue@example.com", "phone": "+44 20 7946 0958" },
"status": 200
}
Output (request-scrubbed.json):
{
"event": "signup",
"user": { "email": "[REDACTED_EMAIL]", "phone": "[REDACTED_PHONE]" },
"status": 200
}Request IDs survive, a real card doesn't
Logs are full of long numeric IDs. The Luhn gate keeps the request ID for correlation and removes only the genuine PAN from a payment debug line.
Input (payment.log):
{"req":"1234567890123456","pan":"4111 1111 1111 1111","status":"declined"}
Output (payment-scrubbed.log):
{"req":"1234567890123456","pan":"[REDACTED_CARD]","status":"declined"}
# req fails Luhn → kept for correlation
# pan passes Luhn → [REDACTED_CARD]Tokens and usernames are NOT redacted
Critical for engineers: the scrubber has no secret or username detector. A bearer token and a username in the log pass through — redact and rotate the token yourself before sharing.
Input (auth.log):
{"auth":"Bearer sk_live_8fJ2kP","login":"jsmith","email":"j@acme.io"}
Output (auth-scrubbed.log):
{"auth":"Bearer sk_live_8fJ2kP","login":"jsmith","email":"[REDACTED_EMAIL]"}
# token + username survive — redact by hand and ROTATE the keyMulti-line stack-trace log with PII in the message
An error log where the email appears in a free-text message line. The scrubber reads raw text, so it's masked regardless of being inside a log message rather than a field.
Input (error.txt): [ERROR] failed to email receipt to sue@example.com at sendReceipt (mailer.js:42) customer phone on file: 0207 946 0958 Output (error-scrubbed.txt): [ERROR] failed to email receipt to [REDACTED_EMAIL] at sendReceipt (mailer.js:42) customer phone on file: [REDACTED_PHONE]
CSV access log — emails masked, IPs kept
An access log exported as CSV. The email column is masked; IP addresses are NOT a detected category and stay (handle them separately if needed).
Input (access.csv): ts,ip,user_email,path 1718200000,203.0.113.7,kit@demo.org,/checkout Output (access-scrubbed.csv): ts,ip,user_email,path 1718200000,203.0.113.7,[REDACTED_EMAIL],/checkout # IP 203.0.113.7 is NOT redacted — no IP detector
Edge cases and what actually happens
API keys, tokens, and secrets are left in the log
By designThere is no detector for bearer tokens, API keys, JWTs, or session secrets — only the six shaped PII categories. A "auth":"Bearer …" line passes through untouched. Before sharing a sanitised log, scan for secrets, redact them by hand, and rotate any key that was ever exposed; the scrub does not protect credentials.
IP addresses aren't redacted
By designIPv4/IPv6 addresses are not one of the six detectors, so an IP in an access log survives. If your privacy review treats IPs as personal data, strip or hash that column separately — this tool won't touch it.
Usernames and internal IDs survive
By designThere's no username, account-ID, or free-text detector. A "login":"jsmith" or an internal user reference passes through. If those are sensitive in your context, redact them by hand or scramble the relevant fields with the CSV/JSON Data Scrambler when the log is tabular.
A request/trace ID isn't masked
PreservedCard matching needs a Luhn-valid 13–19 digit run, so the long numeric request IDs, trace IDs, and epoch timestamps that fill logs are deliberately kept — they're what you need for correlation, not PII. A real card written with a checksum-breaking typo would also be missed, so don't rely on the scrub to catch malformed values.
Only the first file is scrubbed from a multi-select
First file onlyThe drop area accepts several files, but a run scrubs only files[0]. If you captured logs across multiple files, run each separately or call the server-safe API. Check the -scrubbed filename so an unprocessed log isn't pasted into a public tracker by mistake.
A spreadsheet log download is JSON, not a workbook
ExpectedFor .xlsx/.xls/.ods inputs the first sheet is converted to a JSON array of row objects, scrubbed, and returned as that JSON — the filename keeps .xlsx but the content is JSON text. If a downstream tool expects real Excel, save the JSON and re-import, or export the sheet to CSV before scrubbing.
The log file exceeds your plan's limit
Rejected — over limitText logs go through the tier size gate (Free 10 MB, Pro 100 MB, Pro + Media 500 MB, Developer 2 GB). An oversize file throws File "…" is N MB — exceeds the … limit for your plan. and nothing is scrubbed. Trim the log to the relevant window, split it, or upgrade. Spreadsheets are read directly into the tab and bounded by memory.
A long unseparated number is tagged as a card
Card winsDetectors run in a fixed order and the Luhn-gated card pass runs before phone. A long unseparated numeric token that happens to satisfy Luhn becomes [REDACTED_CARD] rather than [REDACTED_PHONE] or staying as an ID. The value is still masked — over-redaction, not a leak — but if you needed that ID for correlation, note it before scrubbing.
An odd phone format in a message slips through
May be missedThe phone detector targets common international and grouped formats with +, parentheses, and space/dot/dash separators. Run-together digit strings or heavily localised formats embedded in a log message may not match. Scan the sanitised log for any phone style your payloads carry that isn't a standard grouped number.
You need to encrypt the log for a trusted vendor instead
Wrong toolIf the vendor is under NDA and needs the *real* log, encrypt rather than redact: use the AES-256 Encryptor (Web Crypto AES-GCM-256, PBKDF2 100k) and send the passphrase out of band. To check the entropy of a suspicious token before deciding how to handle it, see the Entropy Analyzer.
Frequently asked questions
Does it keep my JSON log valid after scrubbing?
Yes. Tags drop inside the existing quoted string values, so a request/response or webhook payload stays valid JSON and can still be pasted into a viewer. The scrubber only substitutes the matched substring; it never reorders, removes, or unquotes fields.
Will it redact API keys, tokens, or secrets?
No. There's no secret detector — only email, phone, IBAN, card, US SSN, and UK NI. A bearer token, API key, or JWT in the log passes through untouched. Scan for secrets, redact them by hand, and rotate any exposed key before sharing the log.
Are IP addresses redacted?
No. IPs aren't one of the six detected categories, so an IP in an access log survives. If your privacy review treats IPs as personal data, strip or hash that column separately — this tool won't touch it.
Is the log uploaded to do the scrub?
No. The on-page tool runs every regex pass locally in your browser tab — the log and the identifiers in it never reach a server through this tool. That's what makes it safe to sanitise before pasting into a public bug tracker or a vendor ticket. A separate opt-in API path exists for automation.
How does it avoid masking request IDs and timestamps as cards?
The card detector applies the Luhn checksum first, so a 13–19 digit run is only masked as [REDACTED_CARD] if it passes Luhn. Request IDs, trace IDs, and epoch timestamps almost always fail Luhn and are kept for correlation. Real cards pass Luhn and are removed.
Can I paste a log straight in, or do I need a file?
This tool works on an uploaded file — there's no paste-text box. Save your clipboard log to a .json or .txt file and drop it in. The sanitised result can then be copied to your clipboard with the Copy button for pasting into a report.
Does it catch PII in nested JSON and free-text messages?
Yes. The scrubber reads raw text, so an email in a nested user.email, a phone in a free-text message, or a card in a payment.debug string are all matched. Structure and key names don't affect detection — only the value content does.
Can I turn off a category I don't want masked?
No. There's no options panel — all six detectors always run and the tags are fixed strings. If you want a masked value back (e.g. you over-redacted an ID), find-and-replace the tag in a text editor afterwards. There is no per-category toggle.
How big a log can I scrub?
Text logs are gated by tier: Free 10 MB, Pro 100 MB, Pro + Media 500 MB, Developer 2 GB. An oversize text file throws an exceeds the … limit for your plan error and isn't processed. Trim the log to the relevant window or upgrade. Spreadsheets are read directly into the tab and bounded by memory.
Which phone formats does it detect in logs?
Common international and grouped formats — an optional +, a 1–3 digit prefix, then digit blocks split by spaces, dots, dashes, or parentheses (e.g. +44 20 7946 0958, (212) 555-0143). Run-together or heavily localised formats may slip; scan the output for any phone style your payloads use.
Can I automate this in my logging pipeline?
There's a server-safe API path that returns { output, redactedCount, counts } as JSON, so you can call it from a script to sanitise logs in a batch. The on-page tool itself is local-only and processes one file per run. Loop the API for multiple files.
What if a suspicious token might be a real secret?
Treat any high-entropy string in a log as a credential: redact it manually and rotate it. To gauge whether a string looks like a random secret versus a plain identifier, check it with the Entropy Analyzer. To encrypt a whole log for a trusted vendor instead of redacting, use the AES-256 Encryptor.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.