Microsoft Presidio alternatives for Node.js and TypeScript (2026)

What is Presidio, and what is it great at?

Microsoft Presidio is an open-source PII detection and anonymization toolkit from Microsoft, written in Python. It splits the job into an analyzer (NER via spaCy models plus a large set of pattern recognizers) and an anonymizer (configurable operators: replace, mask, hash, encrypt).

It deserves its reputation. It is battle-tested, very flexible, supports a wide range of entity types, and was designed for data pipelines: anonymizing datasets, scrubbing logs at rest, de-identifying documents in batch. If that is your workload, especially with GPU budget and a Python team, Presidio is the mature choice and you should use it.

This post is not "Presidio bad". It is about a specific mismatch: TypeScript and Node.js product teams who need redaction on the LLM request path, which is a different job than batch anonymization.

Where is the friction for Node and TypeScript teams?

• It is a Python service you now operate. There is no native Node library, so a TS team runs Presidio as a sidecar or microservice: another deployment, another thing to monitor, another network hop that itself carries the PII.
• No reply-restore round trip. Presidio anonymizes text going in. LLM apps also need the reply mapped back: if the prompt said <PERSON_1>, the answer mentioning <PERSON_1> should reach the user with the real name. Presidio has no built-in vault-backed restore for this; you build and maintain that state yourself.
• Footprint on the request path. spaCy models and their dependencies are hundreds of megabytes and take real memory. Justified for a pipeline node; heavy for a check that runs inside every chat request.
• Streaming is your problem. LLM responses stream, and values split across chunk boundaries defeat per-chunk scanning. Presidio was not designed around token streams, so buffering and boundary handling land on you. We wrote up how subtle that gets in the chunk-boundary bug post.

None of these are design flaws. They are the natural shape of a tool built for data pipelines being pressed into a latency-sensitive request path in a different language.

How do the alternatives compare?

One honest note on that table: Sether's free-text name detection is weaker than Presidio's NER. Sether's identity pack is label-anchored ("name: Sarah Chen" in Latin, CJK, Cyrillic, and Arabic scripts), which is precise but misses names dropped mid-sentence with no cue. When free-text NER is the core requirement, that column favors Presidio, and we say so. The trade-off is explored in Regex vs NER for PII detection.

Which one should you pick for your scenario?

What does a Presidio-to-Sether migration map to?

Conceptually the pieces line up, so a migration is mostly renaming ideas rather than rebuilding them. Presidio's analyzer (recognizers for EMAIL_ADDRESS, PHONE_NUMBER, CREDIT_CARD and so on) maps to Sether's detector packs: the basic pack covers email, phone, card with Luhn, SSN, IPs, and IBAN with mod-97 validation.

Presidio's anonymizer with a replace operator maps to Sether's tokenization, which emits stable tokens like <EMAIL_uuid>. The piece with no Presidio equivalent is the vault-backed restore: Sether keeps the token-to-value mapping (in-memory LRU by default, 10,000 entries with a 1-hour TTL, pluggable if you want your own store) and .restore() maps the LLM reply back.

import { Sether } from '@raeven-co/sether';

const sether = new Sether();

// Presidio analyzer + anonymizer, in one sync call:
const { text: safe } = sether.redactSync(userMessage);

// The part Presidio does not do: restore in the reply
const reply = await callOpenAI(safe);
const { text: restored } = sether.restoreSync(reply);

For streaming, Node streams pipe through sether.redact() and sether.restore(), and there are SSE helpers plus wrappers (wrapOpenAI, wrapAnthropic, wrapFetch) if you would rather not touch the call sites at all. The full setup is in Redact PII before OpenAI in TypeScript.

What you give up: Presidio's breadth of entity types and its NER-first detection. What you gain: no sidecar, a ~35 KB in-process dependency, and streaming restore you do not have to write. Whether that trade is good depends entirely on which column of the decision table you live in.

Why does "lightweight" matter on the request path?

A redaction layer on the request path runs on every single LLM call your product makes. Its latency is added to every response, its memory is resident in every instance, and its dependency tree is attack surface on your most sensitive data flow.

A sidecar adds a network hop that itself carries the raw PII, which means TLS, auth, and availability questions for one more internal service. An in-process library with one runtime dependency keeps the data in the process that already had it. Supply-chain weight matters here too, which is why we documented getting Sether to zero open audit alerts.

The broader picture, including where gateways and browser extensions fit alongside libraries, is in the complete guide to PII redaction for LLM apps.