Sensitive Text Scanner — Flag Potential Personal Data in Text

A PII detector online identifies likely personal or credential-like strings in text, such as email addresses, telephone numbers, payment-card-shaped sequences, internet addresses, and certain secret formats. Paste the passage into the scanner, choose the categories to inspect, and review the matched spans with their character offsets. The detector uses local pattern checks, not identity databases or external validation. It cannot know whether a plausible number belongs to a real person, and a zero-match report does not mean that a document contains no private information.

PII Detector Online At a Glance

What Counts as Personally Identifiable Information in a Text Passage

Personal information is not limited to a single universal list of values. A name, postal address, account reference, contact detail, location or combination of otherwise ordinary facts may identify someone in context. An email address with an unfamiliar domain can still belong to a person, while a generic support inbox may not. A telephone number in an example sentence might be fictional, but the same sequence in a customer record could be private. The scanner therefore describes candidates rather than declaring the legal classification of each piece of text. Its categories are intentionally specific and visible, so a reviewer can understand why a string appeared.

The type of record determines which omissions are dangerous. An employment document may contain names and employee numbers but no bank details; a support export may contain customer correspondence, device identifiers and order references. None of those values necessarily follows a standard regex pattern. Before distributing text, first understand its origin and intended audience. If the source contains highly confidential information, use an approved organizational review process rather than relying on a simple local pattern scan as the only safeguard.

How the Scanner Recognizes Email and Telephone Candidates

An email pattern looks for a local part, the at sign, a domain and a plausible ending. This catches common forms but can miss addresses containing unusual valid international characters, quoted local parts or application-specific formatting. It may also highlight a fictional address in an instructional passage. When a match appears, its displayed character offset helps identify the source context; the label does not assert deliverability or ownership. The tool does not send a test message or query the domain, which avoids implying that the result has been externally checked.

Phone detection is even less definite because international numbers vary in length, separators and national numbering conventions. Dates, serial numbers, payment references and numeric IDs can look like phone numbers when several groups of digits are separated by spaces or hyphens. The detector rejects some obviously implausible lengths and repeated-digit strings, but a plausible candidate is still only a prompt for human inspection. A reviewer who knows the document's geographic context can often distinguish a telephone field from a purchase-order code faster than an automated pattern can.

Card-Like Numbers, Identification Formats and Token Strings

Payment-card-shaped candidates receive an additional Luhn checksum check, a common mathematical filter that reduces accidental matches among arbitrary long numbers. Luhn validity is not evidence that an account exists, is active or belongs to a particular person; many examples deliberately pass the same checksum. The scanner also checks a restricted US Social Security number format and rejects a few impossible digit groups. These patterns are not an exhaustive catalog of national identity numbers, and support for a familiar format should not be mistaken for comprehensive international coverage.

Token-like strings are screened with limited recognizable prefixes. A real API credential may use a different structure, and ordinary application identifiers can resemble secrets without granting access to anything. Treat a flagged token as a potentially sensitive string until the issuing system and its exposure policy are understood. Conversely, do not conclude that unflagged passwords, private keys or session cookies are safe: many have arbitrary encodings and cannot be identified reliably by a fixed prefix. Reviewing source fields and application context remains essential.

Reading Character Offsets and Overlapping Matches

Each match includes a start offset and an end offset so an editor can locate the candidate in the pasted source. These offsets use JavaScript UTF-16 string positions, not physical file byte positions or human-perceived emoji counts. If a passage contains supplementary Unicode characters before a match, its byte offset in a UTF-8 document will differ from the reported location. The displayed value remains the primary reference when you are working within the same text editor. For programmatic pipelines, treat the offsets as positions in the exact input string, without re-encoding or normalizing it first.

Several detection expressions can identify the same digits. A long card-like sequence may also resemble a telephone number, and some identifier formats use segments that another rule could match. To avoid a confusing double count, overlapping candidates are reduced to one result based on a defined priority. This simplifies a human review table, but it can suppress a second possible interpretation. The category label is therefore a best available description of the pattern match, not a full list of every possible identity of the string.

Worked Example: Reviewing a Customer Support Excerpt

Consider a pasted message reading “Contact Mara at mara@example.com or +1 415 555 0123 about invoice INV-00419.” With email and telephone patterns enabled, the scanner should identify the email-shaped string and may flag the telephone-shaped sequence depending on the grouping. The invoice value is not necessarily sensitive by itself and is not automatically classified under a dedicated invoice rule. A reviewer should still inspect it because an invoice number can be confidential when combined with a name, purchase details and an account portal. The result becomes more useful when the editor checks relationships between fields instead of deleting only the highlighted spans.

Suppose the sample also contains a fictional card test number that passes Luhn. The scanner can mark that string even though it is not a working payment instrument. That is a desirable prompt to review rather than a false claim of breach. If the document is intended as a public tutorial, the author can label test values unambiguously or replace them with placeholders. If the document contains real customer records, they should not be moved into public demonstrations simply because their first automated scan produced a small number of findings.

Filtering Categories without Losing Context

Category switches are useful when a review has a particular purpose. A technical log might contain many internal IPv4 addresses, while an exported contact list should emphasize email and telephone fields. Disabling a noisy category makes the report shorter, but it also removes an opportunity to notice a genuine value in that class. Keep a record of which categories were included whenever the JSON report is used as supporting evidence. A clean result under a subset of rules is not comparable to a report obtained with all candidate categories enabled.

It can also help to scan representative excerpts before a long batch. Start with a passage that contains known examples of the kind of data you want to detect and verify that the tool identifies them. Then try counterexamples such as order numbers, calendar dates or names with accented letters to understand false positives and omissions. This exploratory check does not turn a heuristic into an authoritative detector, but it makes its limitations visible to the person who must make the actual release decision.

Exporting Findings and Protecting the Review Record

The JSON report records matched values, labels, offsets and counts. That makes it convenient to reproduce a review decision, yet it also means the exported report may contain the very identifiers the user intended to protect. Store it according to the same confidentiality level as the original passage; do not attach it to a public ticket or paste it into a shared chat without inspection. Copying a JSON report is not the same as producing a redacted source document. The raw text remains in the original editor until you remove it.

A suitable next step is to create an explicitly masked version of the passage and then inspect that version visually. Exact names, unusual reference codes, locations and narrative details often escape automatic pattern rules. Where documents come from PDF exports or a collaboration system, deleting a visible string may leave hidden layers, metadata, comments or earlier revisions. For an initial text-only comparison, the text comparison tool can expose changed lines, but the final release still requires review of the actual file format.

False Positives, False Negatives and Appropriate Use

Any detector that works from syntax alone must balance unexpected matches against missed cases. Strict patterns produce fewer distractions but overlook irregular formats; loose patterns find more candidates but also capture dates and identifiers that carry no personal meaning. The confidence descriptions on this page concern pattern structure, not statistical probability that a person is identified. They are not calibrated risk scores and should not be used as automatic authorization to distribute information.

This workspace is appropriate for inspecting a text excerpt while preparing documentation, reviewing examples or checking a draft report. It is not a substitute for data discovery across attachments, spreadsheets, images, application logs or cloud repositories. Organizations handling regulated records should use approved access controls, retention rules, field-aware scanning and human review. When the cost of disclosure is high, an omitted match is more important than a reassuring total at the top of a report.

Frequently Asked Questions About PII Detector Online

Conclusion

A candidate match should lead to careful examination, not an automatic decision that personal data has been verified or removed. Before releasing an excerpt, inspect values the patterns cannot recognize, check the context that surrounds every remaining identifier and protect the findings report itself if it contains private strings.