PII Data Scrubber & Tokenizer

Why scrub offline?

Most AI tools and prompt processors are server-backed. When you paste a prompt containing internal IPs, API keys, or customer emails into them, the full string is transmitted to a third-party server. For developers working with proprietary code or companies enforcing strict data leak policies, this is a meaningful privacy risk.

What the browser handles locally

This tool uses vanilla JavaScript running entirely in your browser. All ~22 detection types and the tokenization logic happen locally using regex and an in-memory mapping dictionary. You can verify this yourself by opening DevTools, switching to the Network tab, and watching for outbound requests as you type. There are none.

Detection types

PII Scrubber runs about two dozen detection patterns over your pasted text before any scrubbing happens, classifying each match into a typed category that maps to a distinct placeholder token.¹ The categories mirror the split between provider secret patterns and generic secret catch-alls that secret scanning workflows rely on. Developer credentials form one group, covering infrastructure, payment, and service identifiers, while personal data forms the other, covering identity and financial formats governed by compliance frameworks such as GDPR and HIPAA. The detection list below describes every category currently wired into the tool.

• IPv4 addresses: replaced with [IP_1], [IP_2], etc. Use case: internal server addresses, database endpoints, router configs.
• IPv6 addresses: full and compressed forms (::1, fe80::1) replaced with [IP6_1].² Use case: modern network configs, cloud infrastructure addresses.
• Email addresses: replaced with [EMAIL_1].³ Use case: customer contacts, internal team emails in code comments.
• Slack tokens: xoxb- and xoxp- tokens replaced with [SLACK_1].⁴ Use case: bot tokens, OAuth tokens, webhook configs in CI scripts.
• Stripe keys: sk_live_, sk_test_, pk_live_, pk_test_, and rk_live_ keys replaced with [STRIPE_1].⁵ Use case: payment keys in backend configs or .env files.
• Generic API keys: service credential patterns replaced with [API_1]. Use case: AI service keys, internal service keys in config files.
• AWS access keys: AKIA-prefixed keys replaced with [AWS_1].⁶ Use case: AWS access keys in deployment scripts.
• GitHub tokens: GitHub token patterns replaced with [GH_1]. Use case: personal access tokens in CI/CD configs.
• GitLab personal access tokens: GitLab token patterns replaced with [GLPAT_1]. Use case: repository automation, CI/CD pipeline configs.
• Google API keys: Google API key patterns replaced with [GKEY_1]. Use case: Maps, Firebase, or Google Cloud service keys in frontend or server config.
• SendGrid API keys: SendGrid API key patterns replaced with [SENDGRID_1]. Use case: transactional email service keys in deployment configs.
• Twilio Account SIDs: AC-prefixed 34-character hex identifiers replaced with [TWILIO_1].⁷ Use case: SMS/voice service identifiers in communication platform configs.
• NPM auth tokens: npm token patterns replaced with [NPM_1]. Use case: .npmrc files, CI/CD publish tokens for private package registries.
• JWT tokens: compact JWT strings replaced with [JWT_1].⁸ Use case: auth tokens in API request logs or config examples.
• Database connection strings: postgres://, mysql://, mongodb://, and redis:// URLs with credentials replaced with [DBURL_1]. Use case: .env files, Docker Compose configs, deployment scripts.
• Private keys: RSA/SSH/ed25519 PEM private key blocks replaced with [KEY_1].⁹ Use case: PEM files, SSH private key blocks in deployment docs.
• Credit card numbers: payment card number patterns replaced with [CC_1].³ Use case: payment test data, examples in docs.
• Internal domain names: .corp, .internal, .local, .dev, .staging domains replaced with [DOMAIN_1]. Use case: internal service URLs, staging environment hosts in config.
• IBAN bank account numbers: country code, check digits, and BBAN patterns replaced with [IBAN_1].¹⁰ Use case: payroll documents, international wire transfer records, finance team exports.
• US Social Security Numbers: NNN-NN-NNNN format replaced with [SSN_1].¹¹ Use case: HR documents, benefits forms, identity verification workflows.
• Phone numbers: E.164 and common US formats replaced with [PHONE_1].¹² Use case: customer contact lists, CRM exports, HR records.

A concrete pass makes the tokenization easier to picture. Pasting the sentence Contact me at [email protected] or 555-123-4567 into the Scrub tab produces Contact me at [EMAIL_1] or [PHONE_1] in the output textarea, while the Variables panel lists both real values next to their tokens. Sending that scrubbed sentence to an AI reveals only the bracketed placeholders, never the original email address or phone number.

What the patterns catch, and what they leave alone

Every category in the list above is a pattern, and patterns live on structure. The scrubber recognizes an AWS key because it starts with AKIA, an IBAN because the country code, check digits, and BBAN arrive in a defined layout, an internal domain because a suffix like .internal narrows the field. Because the format either matches or it does not, with no judgment call anywhere in the pipeline, an accidental paste of a live credential gets caught cleanly. Structured identifiers announce themselves, which is exactly what makes them both dangerous to leak and easy to strip.

The same discipline draws the honest boundary. A person's name, a street address, a date of birth: none of these have a structural pattern to match, because the same string can be a name, a word in a sentence, or a typo, so the scrubber deliberately leaves them alone rather than guessing and mangling your text. If your prompt names a person or a place in plain prose, that sentence is yours to handle: remove it, rephrase it, or decide the risk is acceptable before you paste the result anywhere. The tool catches the identifiers that carry keys and accounts, and you cover the human details it cannot see.

Borderline content still gets caught when it has recognizable shape. Compressed IPv6 like ::1, internal domain names, and database URLs all sit between obvious and obscure, and each carries a signature the patterns can lock onto, which is why the list includes them at all. For the whole process, the Variables panel is your review surface: read what was detected, confirm each token maps to a value you actually expected, and read the input again for anything the list missed, in that order. Detection is fast; the review is what makes the output trustworthy.

Accuracy has two edges, and you should know both before trusting any scrubber. An unformatted variant, a phone number typed out in words or an SSN with unusual spacing, can slip past a pattern that expects the canonical shape. Conversely, a benign string that happens to look like a key format can be tokenized as a false positive, swapping your harmless text for a placeholder you did not need. Both edges are what the variables list exists to catch: scan it before you send, and a missed value or a suspicious token both surface immediately. Treat that review as part of the tool rather than an optional extra.

Two-way workflow

The scrubber covers both directions of an AI interaction: removing sensitive values before the prompt goes out and restoring them in the AI response that comes back. Without the restoration step, you would need to manually re-insert every token placeholder in the AI's output, which defeats the time savings and introduces transcription errors. Because the mapping dictionary stays in browser memory and never touches a server, you control the link between tokens and real values at all times.

Five-step scrub and restore cycle

Scrubbing and restoration mirror each other across five actions. First, you drop the original prompt or code into the Scrub tab and watch detections populate the variables list the moment you paste. Second, you download that variables file as JSON or CSV, which is the authoritative map connecting each placeholder like [IP_1] back to its real value. Third, you copy the scrubbed text and hand it to your AI tool, which processes the placeholders independently of the underlying sensitive material.

Fourth, you bring the AI response, still full of [IP_1] and [EMAIL_1] tokens, back into the Restore tab. Fifth, you upload or paste the same variables file and click Restore, which walks through the response and swaps every token with the original value. The net result is that the AI never saw the real data, and the response you return to your editor arrives complete and readable without any manual placeholder replacement.

A fair worry accompanies the placeholders: does the AI handle them, or does the answer degrade? A token like [IP_1] carries the role of the value without the value itself, and that role is usually the part the model needs: which address is the client, which one is the database, what kind of identifier the sentence is about. Settle the rest with one instruction line. Add something like "treat bracketed tokens as redacted values and use them as-is" at the top of your prompt, and the model stops asking about them, keeps them intact in its output, and restores cleanly through the Restore tab.

When your PII is not in text form

Text is this tool's entire world, which is worth spelling out before you trust it with anything else. Because the Scrub tab accepts exactly what you paste into it, a scanned document, a screenshot, or a photo never enters the pipeline at all. A scan that contains a name, an address, or an account detail needs optical character recognition before any of it can be tokenized, and the offline OCR redaction tool covers that path by extracting text from images and letting you black out sensitive regions. A photo carries a different leak entirely, the EXIF metadata holding GPS coordinates and device details, and the EXIF metadata scrubber handles that side before the picture goes anywhere.

Security model

This tool processes every piece of sensitive text locally, so the security model depends on keeping the mapping between a token and its real value confined to your browser rather than exposing it to any outside system. Detection, replacement, and restoration all run through vanilla JavaScript with no network call, which means the underlying data never leaves the device you are typing on. The result is a deterministic, one-way mapping that works entirely within the page lifecycle.

How the browser keeps your data local

Each token such as [IP_1] or [DBURL_1] is a placeholder that has no inherent meaning without the variables file, and that file is what ties tokens back to the original values. Because the mapping dictionary lives only in the browser memory and is cleared on page refresh, there is no way to reverse [IP_1] back to 192.168.1.1 without the file present. The tool does not store, log, or transmit any of your data, so the only copy of the sensitive material stays under your control for the duration of the session.

If a secret already went out

Sometimes the paste already happened, and the honest response starts there. A credential that reached any server you do not control is compromised from that moment, because you cannot audit the copies, caches, and backups the request may have passed through on the way. The only sound move is revocation: deactivate the AWS access key, delete or revoke the GitHub token, roll the Stripe key at its provider, and let the automation that used the old credential fail loudly until you update it. Deleting the conversation feels like cleanup. It is not remediation.

Where the revocation happens depends on which credential leaked. AWS documents deactivating and deleting IAM access keys in the IAM console.⁶ GitHub lets you delete a personal access token from your account settings, and a revoked or expired token can no longer authenticate Git or API requests at all.¹³ Stripe's key management page rotates a compromised key, revoking it and issuing a replacement that works immediately.⁵ Each provider keeps the kill switch in its own console, which is the point: the credential's issuer is the only party that can guarantee it stops working. This tool prevents the next leak; it cannot undo the last one, and no amount of scrubbing after the fact changes what already left your machine.

Compliance frameworks and what offline scrubbing covers

Frameworks such as GDPR and HIPAA restrict how personal data and protected health information move to third-party processors. GDPR Article 5 requires personal data to be adequate, relevant, and limited to what is necessary for the processing purpose, while HIPAA's minimum necessary standard asks covered entities to limit protected health information to what is needed for the intended purpose.¹⁴¹⁵ When you use an AI assistant to debug code or draft documentation, the AI provider's API can function as a third-party processor or business associate depending on the workflow and contract. Sending a prompt containing real customer emails, medical record identifiers, or financial account numbers to an AI API can create a disclosure that requires review under your organisation's data governance policy.

Tokenizing before sending reduces the disclosure at the prompt level. The AI receives [EMAIL_1] and [SSN_1] rather than real values, and the tokens remain meaningless without the mapping file that stays on your device. This supports the data minimisation principle in GDPR Article 5: share only what the processor strictly needs to fulfill the purpose. For internal developer workflows where the goal is code review or debugging assistance, the scrubbed prompt contains the context the AI needs without exposing the underlying personal data.

Offline scrubbing does not replace a formal data governance process. Production systems that handle real patient records or financial transaction data need dedicated anonymisation pipelines with audit trails and legal review. What offline tokenization provides is a practical first line of defence for daily developer work: debugging a production log snippet, sharing a database schema with an AI reviewer, or getting query-writing help that references real field names. Handling that kind of ad hoc sensitive exposure takes seconds here instead of requiring a formal anonymisation request or waiting for access to a sanitised environment.