OpenAI dropped a new model on the Hub this week called Privacy Filter. It’s an open-source PII detector that labels text across eight categories in a single pass over 128k tokens. 1.5B parameters, but only 50M active, Apache 2.0 licensed. The model card is worth a read if you’re into the benchmark numbers.
I spent a few hours building with it. Not because I had to, but because the use case is so obviously useful that I wanted to see how it felt in practice. Three apps came out of that session, each showing a different angle of what this model can do when you pair it with a solid backend.
Document Privacy Explorer
This one is exactly what it sounds like: drop in a PDF or DOCX, and the app reads it back with every PII span highlighted in place. The highlights are color-coded by category, there’s a sidebar filter to toggle categories on and off, and a summary dashboard at the top showing counts per type.
The interesting part is how it works under the hood. Because Privacy Filter handles 128k tokens in one forward pass, there’s no chunking or stitching. The span offsets from the model map directly to the rendered text, which means the highlighting is clean and the boundaries don’t drift. BIOES decoding keeps things honest through long ambiguous runs.
I built the frontend as a single HTML file served through gradio.Server. The backend exposes one queued endpoint that takes a file, runs the model, and returns the text with spans and stats. The browser calls it with the Gradio JS client, and the UI handles all the filtering client-side without hitting the model again. That’s the right tradeoff: the model runs once, the UI is fast.
Image Anonymizer
This one is more fun. Upload a screenshot of a Slack thread, a receipt, or a Stripe dashboard, and the app puts black bars over names, emails, account numbers, whatever it detects. You can toggle bars on and off by category, drag them to reposition, or draw new ones by hand for anything the model missed. Then export the result as a PNG at full resolution.
The pipeline is: Tesseract runs OCR and returns per-word bounding boxes. The backend reconstructs the full text with a char-offset-to-box map, runs Privacy Filter once over the whole text, then looks up detected spans against the word map and joins them into pixel rectangles per line.
I could have used gr.ImageEditor for this, but the workflow I wanted per-bar category metadata, category-wide toggles, and client-side PNG export needed a custom frontend. gr.Server hands back pixel rectangles from one queued endpoint and lets the canvas own everything else. The frontend calls the endpoint with the same pattern as the document app, toggles and drags are all local.
SmartRedact Paste
This one is the simplest and maybe the most useful. Paste sensitive text, get a public URL that shows the redacted version, and a private reveal link that shows the original. The model redacts everything in one pass, and the URLs are generated server-side with random tokens.
The backend is just two endpoints: one to create a paste and one to retrieve it. The public endpoint returns the redacted version, the private one returns the original. Both are served through gradio.Server with the queue handling concurrency.
What gr.Server brings to the table
All three apps use gradio.Server the same way. The @server.api decorator plugs each handler into Gradio’s queue, so concurrent uploads are serialized and ZeroGPU allocation works correctly. The same endpoint is reachable from both the browser and gradio_client with no duplicated code.
That consistency is the real win. You don’t need to learn a different pattern for each app. The model runs on GPU, the queue handles the load, the frontend is whatever you want it to be. If you’re building something that needs a custom UI but doesn’t want to manage infrastructure, this is a solid setup.
The model itself
Privacy Filter is genuinely good at what it does. Eight categories: private_person, private_address, private_email, private_phone, private_url, private_date, account_number, secret. State-of-the-art on the PII-Masking-300k benchmark. The 128k context means you can throw a whole document at it without worrying about chunking artifacts.
The Apache 2.0 license is a nice touch. No restrictions on commercial use, no weird attribution requirements. Just a model that works.
What I’d change
The model is solid, but the ecosystem around it is still early. The Hugging Face Spaces examples are functional but feel like demos, not production tools. The documentation assumes you already know how to wire everything together. And the OCR pipeline for images is fragile: Tesseract works fine on clean screenshots but struggles with noisy or low-res images.
That said, the core idea is right. A single-pass PII detector that handles 128k tokens is genuinely useful. The apps I built are proof of concept, but I could see this being used in real workflows for contract review, customer support ticket redaction, or compliance scanning.
Give it a try. The model is on the Hub, the code is on GitHub, and the Spaces are live. It’ll take you an afternoon to build something useful.
Comments (0)
Login Log in to comment.
Be the first to comment!