Nothing leaves your browser. All detection runs locally on your device. Your text is never uploaded, stored, or transmitted. Safe for clinical notes and other sensitive data.
Paste text — a clinical note
support ticket
log
or dataset row — or drop a .txt
.hl7
or .json file.
The tool instantly highlights every detected identifier
color-coded by HIPAA Safe Harbor category.
Adjust the sensitivity slider to control false positives
and click a category to hide or show it.
Toggle Redact to replace findings with tags like [NAME] and [DATE]
then download the redacted text or a JSON report.
Detects all 18 HIPAA Safe Harbor identifier categories — names, dates, phone/fax, email, SSN, MRN, account and license numbers, VIN, device IDs, URLs, IPs, geography, ages over 89, and more.
Every scan runs locally in your browser. Your text is never uploaded, stored, or transmitted — safe for real PHI.
One click replaces findings with category tags. Download the redacted text or a JSON report of every finding with its location and confidence.
Unlike cloud PHI scanners that require uploading your data to a remote API, this tool performs every detection locally in your browser using JavaScript. Clinical notes, support tickets, and log files are never transmitted, cached, or logged anywhere. This is the single most important property for a PHI tool: you can safely run it against real protected health information without creating a new disclosure, and without needing a Business Associate Agreement with a third-party service.
The detector implements all 18 HIPAA Safe Harbor identifier categories rather than a handful of obvious ones. It combines precise pattern matching for structured identifiers (SSNs, emails, phone and fax numbers, dates, IP addresses, VINs, UUIDs) with contextual detection for medical record, account, license, and device numbers, and heuristic detection for names and geography. That breadth means fewer identifiers slip through than with a simple email-and-SSN regex.
A sensitivity control lets you trade recall for precision. At high sensitivity every plausible identifier is surfaced, including low-confidence name and geography guesses; at low sensitivity only high-confidence structured matches are shown. Combined with per-category filtering, you can focus on exactly the identifier types that matter for your dataset and suppress noise, so the highlighted output stays readable on large inputs.
Findings are shown three ways at once: highlighted in place, counted per category in a sidebar, and available as a structured JSON export with character offsets and confidence. A redact mode produces a clean, shareable version of the text with each identifier replaced by its category tag. This supports the real jobs teams do — scrubbing a dataset before model training, sanitizing logs before a support handoff, or spot-checking notes before disclosure.
Under the HIPAA Privacy Rule, health information that identifies an individual — Protected Health Information, or PHI — is tightly regulated. But de-identified data is not: once information can no longer reasonably identify a person, it falls outside HIPAA and can be shared, analyzed, or used to train models. Getting from PHI to de-identified data correctly is therefore one of the most important tasks in healthcare data work, and it is where this tool helps.
HIPAA recognizes two methods for de-identifying data. Expert Determination (45 CFR 164.514(b)(1)) requires a qualified statistician to certify that the risk of re-identification is very small. Safe Harbor (45 CFR 164.514(b)(2)) is the more mechanical route: remove 18 specified categories of identifiers, and provided you have no actual knowledge that the remaining data could identify someone, the result is considered de-identified. Safe Harbor is popular precisely because it is a concrete checklist rather than a statistical judgment — but the checklist must be applied completely.
The Safe Harbor method requires removing all of the following, for the individual and for their relatives, employers, and household members:
Structured fields in a database are relatively easy to de-identify — you know which column holds the SSN. The difficulty lives in unstructured text: clinical notes, discharge summaries, secure messages, support tickets, and application logs, where identifiers appear inline and unpredictably. A physician's free-text note might mention a patient by name, reference their address, and include a phone number and an MRN all in one paragraph. Finding every identifier by hand does not scale, and missing even one can defeat the entire de-identification effort.
Automated detectors layer several techniques. Pattern matching reliably catches structured identifiers with predictable formats — an email always has an @ and a domain, an SSN follows a three-two-four digit pattern, an IPv4 address is four dotted octets. Context rules catch identifiers that are only recognizable by the words around them: a bare alphanumeric string becomes a medical record number when it follows "MRN:". Heuristics and dictionaries handle the fuzziest categories, names and places, using capitalization patterns, honorific titles, and lists of common names and cities. No automated approach is perfect — names in particular produce both false positives and false negatives — which is why a good tool exposes a confidence level and lets you tune sensitivity rather than pretending to be authoritative.
There is an obvious tension in scanning sensitive data for sensitive data: to check whether text contains PHI, something has to read the text. Many online PHI scanners resolve this by uploading your data to a server, which means the very act of checking for a disclosure creates one. Browser-based tools avoid the paradox entirely. Because the detection code runs on your own machine and makes no network calls, your clinical notes and logs never leave your control. You can verify this yourself by opening your browser's developer tools and confirming that no network requests are made while scanning. For anyone handling real PHI, this local-only design is not a nice-to-have; it is the difference between a tool you can legitimately use and one you cannot.
An automated identifier scan is a powerful first pass, but it is not a certification. Safe Harbor also requires that you have no actual knowledge that the residual information could identify an individual, and unusual identifiers — a rare diagnosis, a distinctive quote, an internal case code — may need human judgment to catch. Treat automated detection as a way to do most of the work quickly and consistently, then review the result, especially the "other unique identifier" and free-text portions, before treating the data as de-identified. For high-stakes releases, combine automated tooling with expert review.
They are the 18 categories of information the HIPAA Safe Harbor method requires you to remove to de-identify data: names; geographic data smaller than a state; dates more specific than a year (and ages over 89); phone numbers; fax numbers; email addresses; Social Security numbers; medical record numbers; health plan beneficiary numbers; account numbers; certificate/license numbers; vehicle identifiers; device identifiers; URLs; IP addresses; biometric identifiers; full-face photos; and any other unique identifying number, characteristic, or code.
No. All detection runs locally in your browser using JavaScript. Your text is never uploaded, stored, or transmitted. You can confirm this in your browser's developer tools — no network requests are made while scanning. This makes the tool safe to run against real clinical notes and other PHI.
It helps, but it does not certify de-identification on its own. HIPAA Safe Harbor requires removing all 18 identifier categories and having no actual knowledge that the remaining data could identify someone. Automated detection is an efficient first pass; you remain responsible for reviewing the result, especially free text and unusual identifiers, before treating data as de-identified.
Structured identifiers with predictable formats — emails, SSNs, phone/fax numbers, dates, IP addresses, VINs, UUIDs — are detected with high reliability. Context-based identifiers like MRN and account numbers depend on nearby keywords. Names and geography are the hardest and use heuristics, so they can produce false positives and misses. Use the sensitivity control and review the highlighted output.
It sets the minimum confidence for a finding to be shown. High sensitivity surfaces every plausible identifier, including low-confidence name and geography guesses. Low sensitivity shows only high-confidence structured matches. Lower it to reduce false positives on noisy text; raise it to catch as much as possible.
Yes. Toggle Redact to replace every visible finding with its category tag, such as [NAME], [DATE], or [SSN]. You can then download the redacted text as a .txt file. The redaction respects your sensitivity and category filters, so only the findings you are showing are replaced.
You can paste text directly or drop a .txt, .hl7, .json, .csv, or .log file. The file is read locally in your browser. Input is capped at 1 MB per scan for responsiveness; larger files are truncated to the first 1 MB.
Yes. Download a JSON report listing every finding with its category, confidence, character offsets, and matched text — useful for auditing, building a redaction pipeline, or documenting a review. You can also download the redacted version of the text.
HIPAA treats date elements more specific than a year as identifiers, and it specifically calls out ages over 89 (and any element indicating such an age) because very old ages are rare enough to help re-identify someone. The tool flags full dates and ages of 90 and above; a standalone year is generally permitted under Safe Harbor.
No. This is a reference and productivity tool, not legal advice or a certified de-identification service. Consult your privacy officer, legal counsel, or a qualified statistician for expert determination, and validate any de-identification against the current HIPAA regulations and your organization's policies.
Yes. Once the page has loaded, all detection runs locally with no further network access, so it continues to work with your connection disabled. This is a direct consequence of the client-side, privacy-by-design architecture.
