PII Data Scrubber & Tokenizer

Detect and tokenize sensitive data before sending prompts to AI. Nothing leaves your browser.

ZERO UPLOAD · ALL LOCAL

Before you paste into an AI assistant

  • Credentials and keys API keys, tokens, connection strings and private key blocks become numbered placeholders
  • Contact and network data emails, phone numbers and IP addresses are replaced before the text is copied
  • Variables file download it before you close the tab, or the Restore step has nothing to map back
  • Names and street addresses pattern matching does not catch them, so replace them by hand

Before you share an exported file

  • One paste per related set values that repeat across rows or tables get the same token only within one scrub
  • Structure check open the scrubbed CSV or JSON in its usual reader before you send it
  • Free-text columns names and street addresses in notes or comment fields need a manual pass
  • Variables file keep it apart from the scrubbed file, since together they rebuild the original

Before regulated text reaches an AI tool

  • Pattern identifiers emails, phone numbers, card numbers, SSNs, IBANs and IP addresses are tokenized in one pass
  • Names, addresses and dates remove them by hand, since no fixed pattern identifies them
  • Short card codes CVVs and PINs are too short to detect reliably, so delete them yourself
  • Variables file store it as carefully as the original data, because it maps every token back to a real value

Pre-filled for this page

The input below is pre-filled with 123-45-6789, the example this page refers to, so you can see it flagged and scrubbed immediately.

What to look for

  • 18 categories, all must be removed for de-identified status
  • approximately 8 of the 18
  • 45 CFR §164.502(b)

Removing 17 of 18 identifiers still leaves a record legally identified under HIPAA; Safe Harbor is all-or-nothing.

What to look for

  • up to 4% of global annual revenue or €20 million
  • $7,500 per intentional violation
  • $100 to $50,000 per violation category
  • 60 days, plus a press release if 500+ residents of one state are affected

All PHI is PII, but most PII is not PHI; the health context plus covered-entity requirement is what defines PHI specifically.

What to look for

  • 87% of the US population identifiable from age, gender, and ZIP code (Sweeney)
  • singling out, linkability, and inference
  • anonymization is irreversible; pseudonymization retains a key that allows re-identification

Pseudonymized data is still personal data under GDPR Article 4(5); only true anonymization removes GDPR/CCPA obligations entirely.

What this page covers

  • GDPR Article 4(5) the definition of pseudonymization as a personal-data-reducing technique
  • GDPR Article 32 names pseudonymization as a recognized security measure
  • GDPR Article 89 allows pseudonymized data looser safeguards for research and statistics
  • FF3-1 algorithm NIST SP 800-38G Rev 1, format-preserving encryption that matches the original's character set and length

What to look for

  • 22 sensitive data patterns via regex
  • [EMAIL_1], [EMAIL_2], etc., numbered per unique value
  • session-only, held in browser memory and cleared when the tab closes

Unlike encryption, tokenization has no mathematical relationship between token and original value; security relies entirely on the vault's inaccessibility.

Input (Prompt)

Output (Scrubbed text)

Output (Variables)

  1. Paste your original prompt or code into the input box — detections appear instantly in the Variables section.
  2. Review the detected items in the Variables JSON and the Scrubbed Output textarea with safe placeholders like [IP_1].
  3. Use the Download Variables buttons to save the mapping as JSON or CSV for later restoration.
  4. Copy the scrubbed text and paste it into your AI tool.
  5. Switch to the Restore tab, paste the AI response, upload your variables file, and the restoration happens automatically.

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.

TIP Load the page once while you still have a network connection, then disconnect from the internet and keep using the tool. Every detection pattern, tokenization routine, and mapping operation already lives in your browser, so scrubbing and restoration continue to work offline. This gives you a concrete way to confirm that no outbound request leaves your machine while sensitive text is being processed.

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.1 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.

PII scrubber replacing an email, card number, IP address, AWS key and Stripe key in a prompt with numbered placeholder tokens
The scrubbed prompt swaps the email for [EMAIL_1], the card for [CC_1], the IP for [IP_1], the AWS key for [AWS_1] and the Stripe key for [STRIPE_1]. The order number stays, since it matches no pattern.
  • 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].2 Use case: modern network configs, cloud infrastructure addresses.
  • Email addresses: replaced with [EMAIL_1].3 Use case: customer contacts, internal team emails in code comments.
  • Slack tokens: xoxb- and xoxp- tokens replaced with [SLACK_1].4 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].5 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].6 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].7 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].8 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].9 Use case: PEM files, SSH private key blocks in deployment docs.
  • Credit card numbers: payment card number patterns replaced with [CC_1].3 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].10 Use case: payroll documents, international wire transfer records, finance team exports.
  • US Social Security Numbers: NNN-NN-NNNN format replaced with [SSN_1].11 Use case: HR documents, benefits forms, identity verification workflows.
  • Phone numbers: E.164 and common US formats replaced with [PHONE_1].12 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.

WARNING Treat your downloaded variables file with the same security as the original sensitive data, because anyone who has both the scrubbed text and that file can reconstruct your original prompt in plaintext. Keep the file on an encrypted drive, share it only over trusted channels, and delete it when the restoration work is done so the link between tokens and real values cannot be recovered later.

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.6 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.13 Stripe's key management page rotates a compromised key, revoking it and issuing a replacement that works immediately.5 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.

Cost, offline use and rollout to a team

Three practical questions come up before anyone adopts a scrubber: what it costs, whether it really keeps working without a network, and how a whole team can use it without an IT project. The answers depend on one design choice, which is that every step runs as JavaScript in the browser tab you already have open. That choice removes the server bill, the upload and the deployment at the same time, and the three parts below cover each one in turn.

What the free scrubber includes

Every detection type, both the Scrub and Restore tabs and the variables file download work without an account, a trial or a usage cap. Because the scrubbing happens on your own device, there is no per-request server cost to recover, so a free tier and a paid tier would run exactly the same code. The full details, including the limits of a pattern-based tool, follow.

PII protection shouldn't cost anything. The PII Scrubber on this page is completely free, with no subscription, no account, and no trial period. It detects approximately 21 types of sensitive data and runs entirely in your browser, processing your text locally without transmitting it to any server.

Free browser-based tools for PII protection have historically been rare because the market assumed organizations would buy enterprise DLP software. Conversely, individual developers, freelancers, small teams, and compliance-conscious individuals need the same protection without the enterprise price tag. This tool provides it at zero cost, with no catch.

What the free scrubber includes

The free version includes every feature without restriction: detection of approximately 21 PII types covering emails, phone numbers, SSNs, IBANs, credit card numbers validated by the Luhn algorithm1, IPv4 and IPv6 addresses, all major API key formats from AWS, GitHub, GitLab, Stripe, Google, SendGrid, Twilio, NPM, and Slack, plus JWT tokens, database connection strings, PEM private key blocks, and internal domain names. The two-way workflow supports both scrub and restore operations, the variables file downloads in JSON and CSV format for flexibility, and there is no input length cap on any paste. Consequently, there is no "Pro" version with additional detection types hidden behind a paywall, and all 21 types are available to every user at zero cost with no feature gates.

Why free and local together matter

Most free PII tools are free because they process your data on their servers, which their business model monetizes through analytics or data licensing. A tool that offers free processing with a server upload step does not actually protect your data; it just shifts who holds it from you to a third party with its own data retention policies. Building on this concern, the scrubber is both free and local, which is the combination that actually matters for data protection. CapyToolkit does not monetize user-submitted text because it never sees it. All processing happens in your browser using JavaScript, and the tool is supported by display advertising that does not require access to your input or any data about what you paste.

Limitations of a free browser-based tool

The scrubber works on text that you can paste from any source. It does not process binary files such as PDF, Word, or Excel documents natively, so you need to copy the text content from those files first before scrubbing. Furthermore, the detection patterns are regex-based, which means structured formats like SSNs with dashes and credit card numbers with spaces are reliably caught, but highly varied or custom credential formats that do not follow known patterns may require manual review. For enterprise-grade scanning of large document repositories with thousands of files, a dedicated DLP tool is more appropriate. Yet for the daily use case of scrubbing a prompt before pasting it to an AI tool, the free browser tool handles the vast majority of real-world scenarios with zero setup.

The two-step scrub-and-restore workflow in detail

The scrub step transforms your input text into tokenized output. Paste any text containing sensitive data into the Scrub tab and click Scrub. The tool replaces every detected sensitive value with a unique numbered token and presents both the scrubbed text and a downloadable variables file. The scrubbed text is safe to share with any AI tool or external system. The variables file is the key: it maps each token back to its original value and must be stored securely, separate from the scrubbed text.

The restore step reverses the process after the AI responds. Paste the AI's response (which contains tokens like [EMAIL_1] and [IP_1]) into the Restore tab. Upload the variables file downloaded after the initial scrub. Click Restore. Every token is replaced with the original value from the mapping, producing natural-language output with your real data restored. The restoration runs in your browser in under a second regardless of the response size, and the result is ready to copy without any server interaction at any stage of the workflow.

When to use JSON format versus CSV format for the variables file

The variables file is available in both JSON and CSV format. JSON format stores each mapping as an object with token, original value, and detected type fields, suitable for programmatic processing or import into a secrets management system. CSV format stores the same data in a flat table with columns for token and original value, suitable for opening in Excel or Google Sheets for manual review. For most manual scrub-and-restore workflows, the CSV format is easier to review at a glance. For integration with an automated restoration pipeline, JSON is more convenient because most programming languages parse JSON natively without a CSV parsing step.

Supported data types and how detection confidence varies

The scrubber uses pattern matching against 21 data type definitions to identify sensitive values in pasted text. Each pattern targets a specific format: email addresses use an RFC 5322 subset pattern2, IPv4 addresses use a four-octet numeric pattern with range validation, and credit card numbers use a Luhn-valid digit sequence of 13 to 16 characters3. API key patterns are vendor-specific: AWS AKIA keys match the literal prefix followed by 16 uppercase alphanumeric characters4; GitHub tokens match ghp_ followed by 36 alphanumeric characters; JWT tokens match three base64url-encoded segments separated by dots with the first segment starting with eyJ5.

Detection confidence varies by data type. Email addresses have very high detection accuracy because the format is tightly constrained. SSN detection (three digits, dash, two digits, dash, four digits) is highly specific but misses SSNs presented without dashes. Internal hostname detection (domains ending in .corp, .internal, .local, .staging) has a higher false-positive risk in text that includes words ending in those strings as standalone tokens, which is why reviewing the variables file after each scrub matters most for hostname-heavy content.

Reviewing and correcting the variables file after scrubbing

After each scrub, audit the variables file for false positives before using the scrubbed text in production, and check for any expected sensitive values that are missing from the file (indicating a miss). For numeric fields that appear in the variables file unexpectedly, check whether the number satisfied the Luhn algorithm by matching a credit card pattern. Editing the variables file to remove an incorrect entry is safe: on restoration, tokens without a mapping in the file are left unchanged in the output, making them visible for manual correction rather than silently substituting wrong values.

Building a zero-cost PII governance workflow for small teams

Small teams with no dedicated compliance budget can build a complete PII governance workflow using only the free scrubber and a shared internal document. Create a one-page AI usage guide that lists the three most common scenarios where scrubbing is required (developer AI tools, customer data in support queries, HR data in administrative tools), links the scrubber URL, and describes the two-step workflow in plain language. Pin this document in your team's Slack channel or project management tool so it appears before employees begin any AI-assisted task involving personal data.

Designating one team member as the "PII point of contact" provides an escalation path when employees are uncertain whether a specific text requires scrubbing. The point of contact does not need compliance expertise: they need to know the policy (when to scrub), the tool (the scrubber URL), and who to ask if unsure. This structure maintains governance without requiring a dedicated compliance role or any budget for tooling.

Distributing the scrubber URL across the team without IT deployment

A shared browser bookmark folder exported as an HTML file and imported by each team member installs the scrubber URL in everyone's browser bar without requiring MDM or admin access. Chrome, Firefox, Edge, and Safari all support bookmark import from an HTML file via the browser's settings menu. Include the scrubber URL alongside other commonly used internal tools. Alternatively, add the URL to a team Notion page, shared bookmark manager, or internal tool directory so all team members discover it from the same starting point they use for other tools.

Because the tool is free and runs locally in the browser, sharing the URL costs nothing and adds no data transmission to any server. The variables file each team member downloads stays on their own device, and the same link works for developer prompts, customer data, and HR records without anyone needing an account or an IT provisioning step.

Use this as your default pre-paste step whenever you work with text that might contain sensitive data and you need a free, no-signup tool that processes everything locally.

Freelancer sharing a client report with personal details for AI formatting help

Before
Client report for John Smith ([email protected], +1-415-555-0100). Invoice total: $12,500. Card: 4111111111111111.
After
Client report for John Smith ([EMAIL_1], [PHONE_1]). Invoice total: $12,500. Card: [CC_1].

Developer pasting an error message for an AI debugging session

Before
AuthError: invalid token eyJhbGciOiJSUzI1NiJ9.eyJ1c2VyX2lkIjoiMTIzIn0.abc for user [email protected] from IP 192.168.5.1
After
AuthError: invalid token [JWT_1] for user [EMAIL_1] from IP [IP_1]
Sources for this section
  1. 1.

    "Luhn algorithm," Wikipedia, accessed June 2026. https://en.wikipedia.org/wiki/Luhn_algorithm

  2. 2.

    P. Resnick, "Internet Message Format," RFC 5322, IETF, October 2008. https://www.ietf.org/rfc/rfc5322.txt

  3. 3.

    "Payment card number," Wikipedia, accessed June 2026. https://en.wikipedia.org/wiki/Payment_card_number

  4. 4.

    AWS, "Manage access keys for IAM users," docs.aws.amazon.com, accessed June 2026. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

  5. 5.

    Auth0, "JSON Web Token Structure," auth0.com, accessed June 2026. https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-structure

FAQ

Yes. No subscription, no account, no trial period, no feature gates. All 22 detection types and both workflow tabs (Scrub and Restore) are available at no cost.

CapyToolkit is supported by non-personalized display advertising. No user data is sold or used for ad targeting. The tool itself never sees the text you paste.

No. There is no character limit. Paste a full CSV export, a long log file, or a large JSON payload, and the tool processes the entire content.

Yes. The tool is free for both personal and commercial use. There are no restrictions on commercial usage or on how you apply the scrubbed output in your business workflows.

No. The in-memory variable mapping is cleared when you close or refresh the tab. Nothing is persisted between sessions. Download the variables file before closing if you need to restore later.

Checking that the scrubber runs offline

You do not have to take local processing on trust. Open your browser's developer tools, keep the Network tab visible while you scrub a sample, and watch for requests; then disconnect from the network and run the scrub again. Both checks take under a minute, and the steps below cover air-gapped machines, managed devices and how the browser engine keeps the work local.

Nothing leaves your device. Ever. The PII Scrubber processes all text using JavaScript in your browser tab, with no server requests, no account required, and no upload step. You can load the page, disconnect your internet connection, and the tool will keep working indefinitely on your local machine.

For enterprise teams with strict data egress policies, compliance-conscious individuals, and developers handling GDPR or HIPAA-regulated data, local processing is the only acceptable architecture. Cloud-based PII scrubbers send your text to a server for analysis, which defeats the purpose of pre-scrubbing entirely. The scrubber on this page processes data locally by design, not as a marketing claim.

How to verify local-only processing

Open the browser DevTools (F12 or Cmd+Opt+I), go to the Network tab, then paste text into the scrubber. Zero outbound requests appear. The detection logic, tokenization, and variable mapping all run in the JavaScript bundle already downloaded to your browser. Consequently, you can audit the network behavior yourself without relying on any privacy policy claim. This is the technical definition of local-only: the sensitive data never leaves the execution environment of your browser tab, and every operation from pattern matching to token generation happens within the JavaScript engine already running on your machine.

For security teams that require documented proof, the DevTools Network tab provides a verifiable, repeatable test. Clear the request log, paste any text containing PII, and confirm that no HTTP requests fire during the entire scrubbing operation. This test works identically in Chrome, Firefox, Safari, and Edge, giving your compliance reviewers a hands-on verification method that does not depend on trusting any vendor documentation or privacy policy statement.

Air-gapped and offline use

Load the page once on a network-connected machine. Then disconnect your internet connection or move the machine to an air-gapped environment. The tool continues to work because all necessary JavaScript is already in your browser cache1. Yet each new browser session may require a re-load from the network if the cache is cleared. For repeatable offline use, bookmark the page and load it once at the start of each day. Building on this, the tool's static JavaScript bundle contains everything needed, with no external CDN calls and no runtime API fetches.

For organizations that operate air-gapped networks for regulatory or security reasons, this offline capability is essential. A hospital network that prohibits internet access on clinical workstations can still run the scrubber after the initial page load, because the JavaScript bundle persists in the browser cache without requiring any subsequent network connection. The same applies to financial trading floors, government classified networks, and industrial control systems where internet access is restricted by policy or physical design.

Local processing and compliance frameworks

Under GDPR, processing personal data locally without transmitting it means the data never crosses a border and no data processing agreement with a vendor is required for the scrubbing step itself, because the transfer provisions of Chapter V apply to disclosures to another party.2 For HIPAA, local processing means PHI never reaches a Business Associate's infrastructure, since the scrubber is a client-side tool and not a Business Associate. Under CCPA, California consumer data processed locally stays within the organization. Furthermore, SOC 2 Type II audits that cover third-party vendor risk can exclude locally-run tools from their scope. Conversely, cloud-based PII scrubbers add a vendor relationship that each of these frameworks requires you to manage.

How browser-based local processing works technically

Your browser executes JavaScript in an isolated engine: V8 in Chrome and Edge, SpiderMonkey in Firefox, and JavaScriptCore in Safari3. When the PII Scrubber runs, the JavaScript bundle already delivered to your browser performs all pattern matching and substitution operations entirely within that engine. No WebSocket connections, no fetch() calls, and no XMLHttpRequest events are issued during scrubbing. The only network activity associated with the tool occurs during the initial page load, when the HTML, CSS, and JavaScript files are downloaded from CapyToolkit's servers to your browser cache.

After the initial load, the browser needs no network connection to operate the scrubber. The JavaScript running in your browser tab processes the pasted text, applies 21 regex patterns, builds the token mapping in memory, and generates the scrubbed output and variables file entirely in the browser's RAM. No localStorage, no IndexedDB, and no Cache-API writes occur during scrubbing, so the token mapping is not persisted between page refreshes. Closing the tab releases all memory, including the token mapping.

Verifying local execution with Chrome DevTools

Open Chrome DevTools (F12), select the Network tab, click the clear button (Ctrl+L), and enable "Preserve log." Paste any text into the scrubber and click the scrub button. Watch the Network panel for the duration of the operation. Zero new entries appear because no network requests are made during scrubbing. This test is repeatable and produces the same result in Firefox, Safari, and Edge, providing technical proof of local processing that any developer or security reviewer can independently verify without trusting a privacy policy statement.

Comparing local PII tools to cloud-based DLP services

Cloud-based DLP services such as Google Cloud DLP, AWS Comprehend (detect-pii-entities), and Microsoft Presidio process text on provider servers. Google Cloud DLP supports over 150 InfoType detectors including non-standard formats specific to certain countries and industries4, providing broader coverage than a regex-based browser tool. The trade-off is transmission: sending text to any cloud DLP service means your sensitive data reaches a third-party server for processing, which may require a data processing agreement under GDPR, HIPAA, or CCPA depending on the data category.

Microsoft Presidio is an open-source PII detection framework that runs on your own infrastructure. Presidio is a community-owned open source project originally created at Microsoft, and it deploys as Python packages or Dockerized REST services.5 It combines predefined and custom recognizers using named entity recognition, regular expressions, rule-based logic, and checksums, and the default NLP engine is spaCy.5 That combination covers PII types which resist regex detection, including names, geographic locations, and contextual identifiers, and it can be pointed at the names, locations, and other values a regex-based browser tool cannot classify. For organizations with engineering resources to deploy and maintain an on-premises service, Presidio provides cloud-DLP coverage without the data egress. Note one constraint the project itself flags: because detection is automated, Presidio makes no guarantee that it finds all sensitive information, so layered controls remain necessary. The browser-based scrubber is faster to adopt and requires no infrastructure, making it the practical choice for teams that need immediate coverage without a deployment project.

When cloud DLP makes sense and when local tools are sufficient

Use cloud DLP for systematic, automated PII scanning of large document repositories, production databases, or incoming data pipelines where the volume is too high for manual scrubbing. Pick this over cloud DLP for one-off shares: scrubbing a prompt before an AI interaction, cleaning a CSV before sharing with a vendor, or reviewing a log file before submitting a support ticket. These are interactive, human-in-the-loop workflows where the user is already present and the text volume is small enough that browser-based processing handles it in under a second.

Local processing in regulated environments and managed device policies

Regulated industries often operate on managed devices with browser restriction policies enforced by MDM tools such as Jamf, Microsoft Intune, or VMware Workspace ONE. These policies can block specific URLs, require certificate inspection for HTTPS traffic, and prevent access to non-approved web applications. If your MDM policy restricts access to the CapyToolkit URL, adding it to the MDM allowlist requires demonstrating to your security team that no data egress occurs during scrubbing. The DevTools Network verification method described above provides the evidence needed for that approval without requiring a security architecture review.

Financial institutions and healthcare organizations sometimes deploy DLP browser extensions (such as Symantec DLP Browser Extension or Forcepoint DLP) that intercept clipboard and form submission events to detect PII before it leaves the browser. A local PII scrubber operates entirely within the browser's JavaScript engine and does not involve clipboard events or form submissions to external servers, so these extensions do not conflict with the scrubber's operation or trigger false-positive DLP alerts.

Adding the scrubber to a corporate browser bookmark policy

IT administrators deploying managed browser configurations via Group Policy (Windows) or Jamf (Mac) can push a bookmark to the scrubber URL to all managed devices. Placing the bookmark in the browser's managed bookmarks folder makes the pre-paste workflow accessible from any device in the fleet without requiring employees to find the URL themselves. Including the URL in the browser's new-tab page bookmark bar ensures it appears whenever employees open a new tab before pasting into an AI tool, reducing the friction of making the scrub step habitual.

Because the tool processes everything in your browser with no upload, the bookmark deploys a control that adds zero data egress risk to the managed fleet. Employees reach the scrubber from the same place they already open internal tools, and the variables file they download stays on the local device rather than in a shared corporate store.

Use this for any PII scrubbing task where your organization's policy, compliance framework, or technical security posture requires that sensitive data not leave your local machine.

Healthcare team processing patient records locally

Before
Patient: Jane Doe, DOB: 01/15/1980, SSN: 123-45-6789, Diagnosis: Hypertension, Doctor: [email protected]
After
Patient: Jane Doe, DOB: 01/15/1980, SSN: [SSN_1], Diagnosis: Hypertension, Doctor: [EMAIL_1]

Name and non-identifier clinical data are preserved. SSN and contact email are tokenized locally with no upload.

Legal team reviewing a contract with party contact details

Before
Counterparty: Acme Corp, Contact: [email protected], Phone: +1-212-555-0188, IBAN: GB29NWBK60161331926819
After
Counterparty: Acme Corp, Contact: [EMAIL_1], Phone: [PHONE_1], IBAN: [IBAN_1]
Sources for this section
  1. 1.

    MDN, "HTTP caching," developer.mozilla.org, accessed June 2026. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching

  2. 2.

    Information Commissioner's Office, "International transfers," ico.org.uk, accessed October 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/

  3. 3.

    Node.js, "The V8 JavaScript Engine," nodejs.org, accessed June 2026. https://nodejs.org/learn/getting-started/the-v8-javascript-engine

  4. 4.

    Google Cloud, "InfoType detector reference," docs.cloud.google.com, accessed June 2026. https://docs.cloud.google.com/sensitive-data-protection/docs/infotypes-reference

  5. 5.

    Microsoft Presidio, "Presidio," docs index, accessed October 2026. https://github.com/microsoft/presidio/blob/main/docs/index.md

FAQ

Open DevTools (F12), go to the Network tab, and paste text into the scrubber. No outbound HTTP requests appear. All processing is JavaScript running in your browser tab.

Yes, after the initial page load. Load the page while connected to the internet, then disconnect. The tool continues to function because the JavaScript is already in your browser. For repeated offline use, load once at the start of each session.

No. CapyToolkit requires no sign-up, login, or account. Open the URL, use the tool, close the tab. No data is retained between sessions.

Local processing eliminates the cross-border data transfer concern and removes the need for a data processing agreement with CapyToolkit. Your own compliance posture determines whether local scrubbing meets your specific GDPR obligations, so consult your DPO for formal guidance.

The local processing guarantee applies to the scrubbing step. Once you copy the scrubbed output and paste it into a cloud AI tool, that output travels to the cloud service's servers. The real values are not in the scrubbed output, only tokens, so the cloud transmission contains no original PII.

Rolling the scrubber out across a team

A team rollout needs no installation, because each person opens the same page and the scrubbing stays on their own machine. The work that remains is policy and habit: where the scrub step sits in the AI usage policy, how you train people to use it before every paste, and how it fits next to AI gateways and data loss prevention tools that run on the network instead.

Enterprise data governance starts at the keyboard. When employees use AI tools such as ChatGPT, Copilot, Gemini, or Claude, the PII risk isn't primarily in the tools themselves. It's in the unreviewed prompts that reach those tools before any policy control can act. The scrubber gives enterprise teams a lightweight pre-transmission control that runs in the browser, requires no deployment, and works with every AI tool.

Unlike enterprise AI gateway products that proxy requests through a centralized server, the scrubber operates entirely client-side. Consequently, it adds zero latency to the AI workflow, requires no IT deployment, and can be adopted immediately by any employee in any department, while still satisfying the core governance requirement: sensitive data does not reach external AI providers in identifiable form.

The enterprise AI data governance gap

A 2025 survey found that 83% of organizations have no technical controls to prevent employees from uploading confidential data to AI tools1. Policy-only approaches such as acceptable use policies and mandatory training sessions leave a significant gap between organizational intent and actual employee behavior. Technical controls that operate at the point of input, before the data leaves the device, are the only way to guarantee enforcement at the moment that matters most. Building on this reality, the scrubber acts as a practical point-of-input control: the employee runs the scrub before pasting, and the AI provider only ever receives tokenized output with no identifiable content. For organizations evaluating this approach, the zero-deployment model means teams can adopt the control in minutes rather than waiting months for a gateway procurement cycle.

Enterprise data types the scrubber protects

Enterprise-grade detection covers both developer credentials and business PII across 21 distinct data types. For IT and engineering teams, the scrubber catches IPv4 and IPv6 addresses, API keys across 10 vendor formats including AWS AKIA, GitHub ghp_, GitLab glpat-, Stripe sk_live_, Google AIza, and Slack xox* patterns, along with JWT tokens, database connection strings, and PEM private key blocks. For HR, legal, and finance departments, it detects email addresses, phone numbers, Social Security Numbers, credit card numbers validated by the Luhn algorithm2, and IBAN bank account numbers used in international payroll. Furthermore, internal domain names ending in .corp, .internal, .local, and .staging are detected, which is directly relevant for IT teams sharing network configurations and developers referencing internal service endpoints in debugging prompts. This comprehensive coverage means a single scrubbing pass addresses the full range of sensitive data types that enterprise teams encounter in daily AI workflows.

Deployment and adoption patterns

The scrubber requires no IT deployment, no software installation, and no account provisioning, which removes the traditional barriers that delay security tool adoption by months. Employees access it at a public URL from any corporate or personal device, and the entire onboarding process takes under five minutes from first visit to first successful scrub. For organizations that need to control and standardize access, the tool URL can be bookmarked in managed browsers via Group Policy, linked directly from AI policy documentation, or included in AI tool usage guidelines distributed during security onboarding. Large enterprises with dedicated AI gateway infrastructure may prefer server-side data classification that operates transparently without employee action, but the scrubber serves a different niche: mid-size teams and departments within large organizations where centralized gateway deployment is not yet approved, funded, or implemented.

Enterprise AI gateway products compared to browser-side controls

Enterprise AI gateway products such as Nightfall AI, Protect AI's Lakeera Guard, and Cloudflare AI Gateway intercept AI API requests at the network level, scanning request payloads for PII before they reach the AI provider.3 These products operate at the organization's egress point: every API call to ChatGPT, Claude, or Copilot passes through the gateway, which applies DLP rules and blocks or redacts matching content before forwarding the request. Gateway deployments provide enforcement regardless of which tool or device the employee uses, because the interception happens at the network layer. Cloudflare documents the mechanism precisely: DLP policies are configured at the gateway level and apply uniformly to all requests passing through that gateway, with no per-request header to bypass scanning.3

The deployment cost of gateway products is significant. Network-level interception requires routing all AI traffic through a proxy server or CASB integration, which adds latency to every request and requires integration testing across all AI tools in use. Cloudflare's own documentation notes a concrete latency cost: when DLP response scanning is enabled on a streaming request, the gateway buffers the full response before inspecting it, so time-to-first-token latency rises in proportion to total generation time. DLP rule calibration requires ongoing maintenance to avoid blocking legitimate use while catching actual policy violations. For mid-size organizations without a dedicated security engineering team, a browser-side scrubbing control deployed via a bookmarked URL provides the same protection at the point of human decision-making, at zero infrastructure cost.

Layering a browser scrubber with an enterprise gateway

For organizations that deploy both a gateway and a browser scrubber, the two controls operate at different layers and complement each other. The scrubber's job is to catch data before the gateway ever sees it, working before the prompt is constructed and before the API call is made. The gateway catches any sensitive data that slips through the scrub step, either because the employee forgot to scrub or because the data type was outside the scrubber's 22 patterns. Defense-in-depth with both layers reduces residual risk more than either control alone.

Training employees to use a browser scrubber before AI tools

Employee training for PII protection before AI tool use requires framing the scrubber as a capability enabler rather than a compliance burden. Staff who understand that scrubbing lets them use AI tools with any data, regardless of sensitivity level, adopt the habit faster than staff told only to "avoid AI for sensitive data." The message is: the scrubber removes the restriction, not the tool. Pair this framing with a practical 10-minute demonstration showing the scrub-and-restore workflow for a realistic work scenario relevant to each team's daily tasks.

Training sessions that include a live demonstration produce higher adoption than those relying solely on written guidelines. A 10-minute session covering three scenarios (an HR prompt with employee data, a developer config file with credentials, and a customer support query with personal details) gives employees the pattern recognition they need for their own tasks. Recording the session and linking it from the team's AI policy page provides a reference for employees who join after the initial training rollout.

Including the scrubber in AI acceptable use policies

An AI acceptable use policy that mentions the scrubber by URL alongside a plain-language description of when to use it (before pasting any customer, employee, or financial data into an AI tool) gives employees a concrete action item alongside the policy rule. This matches what NIST's Generative AI Profile asks of organizations: it recommends defining acceptable use policies for generative AI systems deployed by, used by, and used within the organization, and naming the specific categories of data those policies govern.4 Policies that prohibit sensitive data in AI tools without providing a compliant workflow leave employees choosing between compliance and productivity. A policy that provides the scrubber URL gives them both, converting a restriction into a procedure they can follow immediately.

Tracking AI tool usage in organizations without a deployed gateway

Without a deployed AI gateway, the most practical signal of AI tool usage patterns is browser history on managed devices. MDM tools that enforce Safe Browsing reporting or that integrate with Cloudflare Zero Trust can surface which AI tool domains employees visit most frequently, without inspecting the content of those visits. Surfacing this data in a monthly report to the security team identifies which AI tools see the most usage, which departments use them most heavily, and whether usage is concentrated in teams that handle high-sensitivity data.

Network-level DNS logs provide a complementary signal. A DNS request to api.openai.com, api.anthropic.com, or generativelanguage.googleapis.com indicates an AI API call from a device on your corporate network5. Correlating DNS query volume with the user list for that network segment gives a usage signal without payload inspection. For organizations with a pfSense, Palo Alto, or Cisco Umbrella DNS infrastructure, configuring alert rules on AI provider domains takes under an hour and requires no agent deployment on endpoints.

Deploying a lightweight DLP browser extension for employee awareness

Browser DLP extensions such as Saaslio can highlight when text pasted into any web form matches credential or PII patterns, prompting the user to review before submission. These extensions operate in the browser without a centralized server-side component, making them deployable without infrastructure changes. Pairing a DLP extension with the scrubber provides a second checkpoint: the extension detects credentials in the paste before they enter the AI tool's input field, reminding the employee to run the scrubber first as part of the workflow.

Combining the extension with the scrubber gives employees two prompts to scrub before any paste, which raises the chance the step is not skipped. CapyToolkit runs the scrub locally in the browser, so the pairing requires no central server and adds no latency to the AI workflow, making it practical to roll out across every department at once.

Use this as a pre-transmission control before any employee shares internal data with an AI tool, and as a training demonstration for enterprise AI usage policy rollouts.

IT team sharing infrastructure config for AI analysis

Before
Our prod setup: db at postgres://ops:[email protected]:5432/main, Redis at redis.cache.internal:6379, API GW at 10.0.1.1
After
Our prod setup: db at [DBURL_1], Redis at [DOMAIN_1]:6379, API GW at [IP_1]

Finance team pasting a vendor payment record for AI-assisted review

Before
Vendor: Acme Ltd, IBAN: DE89370400440532013000, Contact: [email protected], Amount: EUR 4,500
After
Vendor: Acme Ltd, IBAN: [IBAN_1], Contact: [EMAIL_1], Amount: EUR 4,500
Sources for this section
  1. 1.

    Kiteworks, "The 2025 AI Security Gap: Why 83% of Organizations Are Flying Blind," kiteworks.com, August 2025. https://www.kiteworks.com/cybersecurity-risk-management/ai-security-gap-2025-organizations-flying-blind/

  2. 2.

    "Luhn algorithm," Wikipedia, accessed June 2026. https://en.wikipedia.org/wiki/Luhn_algorithm

  3. 3.

    Cloudflare, "Data Loss Prevention (DLP)," AI Gateway documentation, developers.cloudflare.com, updated September 2026. https://developers.cloudflare.com/ai-gateway/features/dlp/

  4. 4.

    NIST, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile," NIST AI 600-1, nist.gov, July 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

  5. 5.

    Anthropic, "API overview," platform.claude.com, accessed June 2026. https://platform.claude.com/docs/en/api/overview

FAQ

No. It runs entirely in the browser. Employees access it at a URL with no installation, no account provisioning, and no server setup required.

Enterprise AI gateways proxy all AI requests through a centralized server and can classify data in transit. The scrubber is a point-of-input control that operates before the request is made. Both approaches solve different parts of the problem: gateways are comprehensive but complex to deploy, while the scrubber is immediate and adoption-ready.

Yes. You can link directly to the tool URL in your policy documents. Employees can bookmark it or be directed to it as the required pre-paste step before using any external AI tool with internal data.

CapyToolkit is a free browser-based tool. No enterprise contract is available. For enterprise-grade compliance tooling with SLAs, audit trails, and centralized administration, consider dedicated DLP or AI gateway vendors.

The scrubber is a voluntary control that requires employee action. For mandatory enforcement, combine it with AI gateway policies, browser extensions, or DLP rules that block unscanned text from reaching AI endpoints. The scrubber works best as part of a defense-in-depth approach.

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.1415 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.

What Got Scrubbed Checklist

  • Developer credentials tokenized IPs, API keys, and provider tokens such as AWS, GitHub, GitLab, Slack, Stripe, Google, SendGrid, Twilio, and NPM keys, plus JWTs, database connection strings, and PEM private keys, all show up as bracketed placeholders like [AWS_1] instead of the original value.
  • Personal PII tokenized Emails, phone numbers, Social Security Numbers, credit card numbers, and IBANs show up as placeholders like [EMAIL_1] or [SSN_1].
  • Internal domains tokenized .corp, .internal, .local, .dev, and .staging hostnames show up as [DOMAIN_1].
  • Variables file saved before sending The downloaded JSON or CSV mapping file is stored somewhere secure before the scrubbed text goes anywhere else, since it is the only way to restore the original values later.

Paste your own prompt above and confirm every sensitive value in it turned into a bracketed token before you send it anywhere.

Sources
  1. 1.

    GitHub, "Supported secret scanning patterns," docs.github.com, accessed June 2026. https://docs.github.com/en/[email protected]/code-security/secret-scanning/introduction/supported-secret-scanning-patterns

  2. 2.

    R. Hinden and S. Deering, "IP Version 6 Addressing Architecture," RFC 4291, IETF, February 2006. https://www.rfc-editor.org/rfc/rfc4291

  3. 3.

    Mozilla Developer Network, "autocomplete HTML attribute," developer.mozilla.org, accessed June 2026. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete#autocomplete-parameters

  4. 4.

    Slack, "Tokens," docs.slack.dev, accessed June 2026. https://docs.slack.dev/authentication/tokens

  5. 5.

    Stripe, "API keys," docs.stripe.com, accessed June 2026. https://docs.stripe.com/keys

  6. 6.

    AWS, "Manage access keys for IAM users," docs.aws.amazon.com, accessed June 2026. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

  7. 7.

    Twilio, "What is a String Identifier (SID)?," twilio.com, accessed June 2026. https://www.twilio.com/docs/glossary/what-is-a-sid

  8. 8.

    M. Jones, J. Bradley, and N. Sakimura, "JSON Web Token (JWT)," RFC 7519, IETF, May 2015. https://www.rfc-editor.org/rfc/rfc7519

  9. 9.

    S. Josefsson and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures," RFC 7468, IETF, April 2015. https://datatracker.ietf.org/doc/html/rfc7468

  10. 10.

    ISO, "ISO 13616-1:2020 - Financial services - International bank account number (IBAN) - Part 1: Structure of the IBAN," iso.org, September 2020. https://www.iso.org/standard/81090.html

  11. 11.

    SSA, "POMS: RM 10201.030 - Structure of the Social Security Number (SSN)," secure.ssa.gov, June 2011. https://secure.ssa.gov/poms.NSF/lnx/0110201030

  12. 12.

    ITU, "E.164: The international public telecommunication numbering plan," itu.int, accessed June 2026. https://www.itu.int/rec/T-REC-E.164/en

  13. 13.

    GitHub, "Token expiration and revocation," docs.github.com, accessed September 2026. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation

  14. 14.

    European Union, "Regulation (EU) 2016/679 Article 5: Principles relating to processing of personal data," legislation.gov.uk, accessed June 2026. https://www.legislation.gov.uk/eur/2016/679/article/5/adopted?view=plain

  15. 15.

    U.S. Department of Health and Human Services, "Minimum Necessary Requirement," hhs.gov, accessed June 2026. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

FAQ

No. The tool does not collect, store, transmit, or log any text you paste. All detection and tokenization happen entirely in your browser using vanilla JavaScript. The mapping dictionary lives in memory and is cleared when you refresh the page.

The tokens are just text placeholders. The AI sees [IP_1] and generates a response using that placeholder. When you paste the AI response back into the Restore tab and upload your variables file, the tool replaces every [IP_1] with the original IP address. The AI never saw your real data.

Around 22 types across two categories. Developer credentials: IPv4 and IPv6 addresses (including compressed forms like ::1), generic API keys ([API_1]), AWS access keys ([AWS_1]), GitHub tokens ([GH_1]), Slack tokens ([SLACK_1]), Stripe keys ([STRIPE_1]), Google API keys ([GKEY_1]), SendGrid keys ([SENDGRID_1]), Twilio Account SIDs ([TWILIO_1]), NPM auth tokens ([NPM_1]), GitLab PATs ([GLPAT_1]), JWT tokens ([JWT_1]), database connection strings ([DBURL_1]), and PEM private key blocks ([KEY_1]). Personal PII: email addresses ([EMAIL_1]), credit card numbers ([CC_1]), US Social Security Numbers ([SSN_1]), phone numbers in E.164 or US format ([PHONE_1]), IBAN bank account numbers ([IBAN_1]), and internal domain names ([DOMAIN_1]). Each unique value gets its own incrementing token number.

If you ask an AI to scrub data, you have already sent the sensitive information to it. The leak happens the moment your prompt reaches the AI server. This tool runs entirely offline in your browser, so the sensitive data never leaves your device in the first place.

Yes. After scrubbing, download the variables as a JSON or CSV file. This file maps each token back to its original value. CapyToolkit does not upload or backup this file. Keep it secure, as anyone with this file and the scrubbed text can reconstruct your original data.

There is no way to restore the original values without the mapping file. The tokenization is one-way by design. [IP_1] cannot be reverse-engineered back to 192.168.1.1 without the mapping. Treat the downloaded JSON or CSV file the same way you would treat the original sensitive data: store it securely and delete it when no longer needed.