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.

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.

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.

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.