Why in-browser processing protects your data

In-browser (“client-side”) processing protects your data because it never leaves your machine: detecting and replacing sensitive data runs locally, in memory, without going through a server. So there is nothing to intercept, log or leak on the backend. It's a design guarantee (“privacy by design”), not just a contractual promise.

Client-side vs server-side: where does data live?

In a server-side architecture, your text goes to a server that processes it: you then have to trust that server (encryption, retention, access, jurisdiction). In a client-side architecture, processing happens in your browser: the server never sees the raw data. The difference is structural, not just contractual.

• Nothing to intercept: the sensitive data isn't transmitted.
• Nothing to log: no content to retain server-side.
• Reduced surface: fewer exposed components = fewer risks.
• Verifiable: network behavior can be observed (DevTools).

The mapping stays local: the key doesn't leave

When you anonymize a prompt, the token ↔ original-value mapping is the most sensitive piece. Keeping it in browser memory — and never transmitting it — guarantees no one else can re-identify. That's what turns tokenization into real protection.

The limits to know

Client-side protects data as long as it stays local. As soon as anonymized text is deliberately sent to an AI service, it's that text (without PII) that travels — not the mapping. The challenge then becomes detection quality: what isn't detected isn't anonymized. Hence the importance of broad, context-aware coverage.

ONYRI Sanitize's engine runs 100% in the browser: the token ↔ value mapping never travels to the backend. Only already-anonymized text can, on an opt-in basis, go to an AI model.