How client-side processing works
snip.tools is built around a simple promise: your data stays on your device. Most of our tools never send what you type, paste, or open to a server at all.
Everything runs in your browser
Each tool is a small program that executes locally using JavaScript and, for heavier work like image and PDF processing, WebAssembly. When you compress an image or format a JSON document, the work happens on your own machine. Nothing is uploaded, stored, or logged on our side.
How to verify it
The “runs in your browser” claim is something you can check. Open your browser's developer tools and watch the Network tab while using a client-side tool. Formatting JSON, compressing an image, merging a PDF, or decoding Base64 should not upload your input or files to us or to a third-party service.
The site also ships a Content-Security-Policy that restricts which scripts, frames and
network destinations a page may use. Because snip.tools uses privacy-friendly analytics, Cloudflare
Turnstile on the contact form, and Google advertising/consent services, the production policy is not a
pure connect-src 'self' rule. The important boundary is narrower and easier to audit: the tool
code processes your pasted text and opened files locally, and those inputs are not sent to those services.
- Use the Network tab to confirm the tool does not upload your content.
- Inspect the response headers (for example with
curl -I https://snip.tools/) to read the policy directly.
The few tools that query public data
Some lookups — WHOIS, DNS, SSL inspection — have to ask a public registry a question, so they send the single identifier you enter (a domain, an IP) through a minimal proxy. They never receive a file, and those pages are clearly labelled so the distinction is always obvious.
Open-source modules
As our file-processing modules mature, we publish them as open-source packages so anyone can audit exactly what runs on their device.