PII Detector & Redactor
Paste text below and Lucenta will find and redact emails, phone numbers, credit card numbers, SSNs, and IP addresses — instantly, no model call required.
Pattern-based detection, running entirely at the edge
Personally identifiable information doesn't announce itself — it shows up mid-sentence in a support ticket, pasted into a chat message, or sitting quietly in a log line nobody meant to capture. Unlike the profanity checker, the PII redactor doesn't call an AI model at all: structured personal data like emails, phone numbers, and card numbers follow reliable, well-known formats, so pattern matching finds them faster and more deterministically than a model would. Here's exactly how the detection works, how it compares to AI-based redaction, how to integrate it, and where it draws the line.
How the detection actually works
The redactor runs your submitted text against five ordered regular-expression patterns — email addresses, US Social Security numbers, IPv4 addresses, credit card numbers, and phone numbers — each tuned to match the real-world formatting variance those fields actually appear in (dashes, dots, spaces, parentheses, and so on).
Credit card matches get one extra step: every 13–19 digit sequence that matches the shape of a card number is run through the Luhn algorithm, the same checksum real card numbers are required to satisfy, before being reported. That single check eliminates the majority of false positives from order numbers, tracking codes, or other long digit sequences that merely look like a card number at a glance.
Because patterns can overlap — a phone number pattern can partially match inside a longer digit sequence, for instance — matches are sorted by position and de-duplicated so the leftmost, highest-priority match wins on any overlap, rather than double-reporting or corrupting the redacted output.
There's no embedding step and no external model call anywhere in this path, which is why it's the fastest endpoint in the suite — typically single-digit milliseconds, running entirely on Cloudflare's edge network. The output is deterministic: the same input always produces the same entities and the same redacted text, which matters if you're logging or auditing redaction behavior.
Pattern order matters more than it might seem. SSNs, IPv4 addresses, and credit card numbers are all sequences of digits with optional separators, which means a naive implementation could easily double-match the same span under two different types, or let a looser pattern swallow part of a stricter one. Ordering the patterns deliberately — checking the more specific, more constrained formats first — and then de-duplicating overlapping spans by position keeps every character of your text attributed to exactly one entity, or none.
Pattern matching vs. AI-based (NER) redaction
Some redaction tools use a named-entity-recognition (NER) model instead of patterns. Both approaches are legitimate — they're just suited to different kinds of data.
| AI / NER-based redaction | Lucenta (pattern-based) | |
|---|---|---|
| Emails, phone numbers, card numbers, SSNs | Usually accurate, but slower and non-deterministic | Fast, deterministic, and precise — these fields follow strict formats |
| Free-form PII (names, home addresses) | Better suited — NER models are trained to recognize unstructured entities | Not covered — outside the scope of pattern matching (see limitations) |
| Latency | Typically tens to hundreds of milliseconds per model call | Single-digit milliseconds — no model call at all |
| Determinism / auditability | Can vary between runs depending on the model | Same input always produces the same output |
| Cost at scale | Scales with model inference cost | Negligible — regex and a checksum are effectively free to run |
| False positives on card-shaped numbers | Depends entirely on model training data | Reduced via Luhn checksum validation before reporting a match |
Wiring it into your product
Same shape as every other Lucenta endpoint — one HTTP call, structured JSON back.
- 1
Get an API key
Head to /get-started and enter your email — I'll send you a sign-in link, and your dashboard (and first key) is ready the moment you click it. No password, no waiting.
- 2
Send the text
POST to /v1/redact with your key in the x-api-key header. There's a 2,000 character limit per request.
- 3
Choose a mode
"redact" (the default) returns a redactedText field with entities replaced by labels like [EMAIL]. "detect" skips the rewrite and just returns the list of entities found — useful if you want to flag content for review without altering it.
- 4
Handle the entities array
Every match includes its type, the matched value, and its start/end character offsets in the original text — enough to build your own custom redaction or highlighting on top of the raw detections if the default label format doesn't fit your UI.
Example request & response
curl https://api.lucenta.dev/v1/redact \
-H "content-type: application/json" \
-H "x-api-key: YOUR_KEY" \
-d '{ "text": "email jane@example.com", "mode": "redact" }'
{
"entities": [
{ "type": "email", "value": "jane@example.com", "start": 6, "end": 22 }
],
"redactedText": "email [EMAIL]",
"latencyMs": 1
}Response fields, in detail
Every match includes enough detail to build your own redaction or highlighting logic, not just the default [LABEL] format.
entitiesarray- Every detected piece of PII, sorted by position in the text and de-duplicated where patterns overlap.
entities[].typestring- One of "email", "phone", "ssn", "ip_address", or "credit_card".
entities[].valuestring- The exact matched substring from your original text, unredacted — useful for your own logging or review UI, but handle it with the same care as the source text.
entities[].start / entities[].endnumber- Character offsets of the match in the original text, so you can build custom highlighting or redaction instead of relying on the default [LABEL] replacement.
redactedTextstring- Only present when mode is "redact" (the default) — your original text with every detected entity replaced by a label like [EMAIL] or [PHONE].
latencyMsnumber- Server-side processing time in milliseconds — typically in the single digits, since this endpoint makes no model call.
Common use cases
A few places teams typically wire this in:
Support tickets & chat transcripts
Strip personal data out of tickets and transcripts before archiving them long-term, so historical support data doesn't become a growing pile of unredacted PII. Customers routinely paste card numbers, phone numbers, and email addresses into free-text fields even when a form never asked for them, simply because that's where the context of their problem lives.
Logs & error reports
Sanitize log lines and error payloads before they're shipped to a third-party monitoring or observability tool you don't fully control the retention policy for. A stack trace that happens to include a user's input at the point of failure is a common, easy-to-miss way personal data ends up somewhere it shouldn't.
Pre-processing before an LLM
Redact user-submitted text before sending it to a third-party LLM or support chatbot, so personal data never leaves your own infrastructure in the first place. This is usually far simpler than trying to negotiate or audit a third party's data-handling terms after the fact.
Form input sanitization
Catch personal data accidentally pasted into the wrong field — a phone number in a "notes" box, for instance — before it's persisted anywhere. Free-text fields are the most common place structured PII ends up somewhere your schema never expected it.
Dataset scrubbing
Run bulk user-generated content through the endpoint before using it for analytics, model fine-tuning, or any other secondary use it wasn't originally collected for. Because the output is deterministic, you can re-run the same scrub repeatably as your dataset grows.
Compliance-adjacent workflows
Use it as an automated first pass ahead of a manual data-handling review for GDPR, CCPA, or similar regulatory obligations — see the limitations below on where it stops short of a full compliance guarantee. Automating the obvious, structured cases frees up a human reviewer to focus on the ambiguous ones.
Content moderation pipelines
Pair it with the profanity checker to screen both toxicity and personal data in the same moderation pass on user-submitted text, since both endpoints share the same request shape and API key.
Where the redactor's limits are
Pattern matching is precise for structured data, but precise and comprehensive aren't the same thing.
- It does not detect names, home addresses, or other free-form personal data — only the five structured pattern types it's built for (email, phone, SSN, IPv4, credit card).
- Phone number and SSN patterns assume US-style formatting; other countries' formats aren't currently covered.
- This is a detection aid, not a compliance guarantee — treat it as a first pass, not a substitute for a proper data-handling review for regulated use cases.
- The Luhn check reduces credit-card false positives significantly but can't eliminate them entirely — some non-card digit sequences will still coincidentally pass the checksum.
- Requests are capped at 2,000 characters — for longer documents, chunk them client-side and redact each piece.
- It processes text only — PII embedded in images, PDFs, or audio isn't covered by this endpoint.