Local PII Scrubber: No Uploads, 100% Offline

Local PII Scrubber: No Uploads, 100% Offline Processing

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 cache¹. 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. 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 Safari². 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 industries³, 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. You deploy it as a Docker container or a Python library and process all text within your environment. Presidio supports named entity recognition using spaCy models for PII types that resist regex detection, including names, geographic locations, and contextual identifiers. For organizations with engineering resources to deploy and maintain an on-premises service, Presidio provides cloud-DLP coverage without the data egress. 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.

When to use this

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.

Examples

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

Patient: Jane Doe, DOB: 01/15/1980, SSN: [SSN_1], Diagnosis: Hypertension, Doctor: [EMAIL_1]

Counterparty: Acme Corp, Contact: [email protected], Phone: +1-212-555-0188, IBAN: GB29NWBK60161331926819

Counterparty: Acme Corp, Contact: [EMAIL_1], Phone: [PHONE_1], IBAN: [IBAN_1]