Every privacy policy says the same thing. "We respect your privacy." "We take your security seriously." "We only collect what we need." You've read some version of that sentence a thousand times and it has never once meant anything specific enough to hold anyone accountable.
Here's what's different about AppCrib: our privacy policy doesn't matter. Not because we don't have one (we do), but because the architecture makes it irrelevant. We don't have your data in the first place. There's nothing to promise about.
How do free tools actually make money from your data?
You Google "JSON formatter," land on whatever ranks first, paste your production API response into a text box, and hit Format. That JSON hit a server. It got logged. Your IP address was attached. The tool is "free" because your data and attention are the product. The formatting is just the bait.
Same for image tools. Upload a photo to strip metadata, and now some server in a data center you can't name has your image, your EXIF data (GPS coordinates, device serial numbers, timestamps), and your IP. You came to protect your privacy and ended up handing over more of it.
Every data point has a price. Even if the tool operator isn't actively selling your data (and plenty are), they're sitting on it. One breach, one acquisition, one policy change, and those "we respect your privacy" promises evaporate overnight.
What does client-side processing actually mean?
Client-side processing means the tool runs entirely in your browser. Your data never leaves your device. No upload, no server round-trip, no log entry.
Blank strips EXIF metadata from photos (GPS coordinates, camera serial numbers, timestamps) in JavaScript running in your browser tab. The image never leaves your machine. When you download the cleaned file, it comes from your own device's memory. No server ever saw it.
jsonr formats JSON the same way. Paste your API response, your config file, whatever. It formats locally because there is no backend. The tool is a static file served from a CDN. It runs, it formats, it's done.
Jqbin takes this further. It runs the actual jq binary inside your browser. Real jq 1.8, the genuine C codebase compiled to WebAssembly. Not a "jq-like" JavaScript reimplementation. The real thing, running locally. Your data never leaves the tab.
The architecture is the guarantee. That's what client side privacy web tools should actually look like.
Why can't you just trust a privacy policy?
Because a privacy policy is a legal document, not a technical control. It describes intentions. It doesn't enforce them.
A privacy policy can say "we don't log your data" while server access logs capture every request body by default. It can say "we don't sell your data" while a third-party analytics SDK phones home to fourteen endpoints. The document and the infrastructure have nothing to do with each other.
The only privacy guarantee that holds is one where the data never exists outside your control. Everything else is a promise, and promises are only as good as the incentive structure behind them. When a free tool is funded by data collection, that structure is pointing the wrong way.
How does AppCrib enforce this at the technical level?
Start with the build. Every tool on AppCrib is a Next.js app compiled with output: "export", a fully static build. No server-side rendering, no API routes, no Node.js process handling requests. The output is HTML, CSS, and JavaScript served from Cloudflare's CDN. There is no server to log your data to.
On top of that, every tool ships with Content-Security-Policy headers. A CSP that explicitly lists which domains the page is allowed to contact. A typical one looks like this:
connect-src 'self' https://*.posthog.com https://*.convex.site
That connect-src directive is a hard browser-enforced constraint. The page cannot make network requests to any domain not on that list. If someone injected a malicious script, the browser itself would block the exfiltration. Open DevTools, check the headers, verify it yourself.
Permissions are locked down too. Permissions-Policy: camera=(), microphone=(), geolocation=(). The page can't access your camera, mic, or location even if it tried.
What about analytics? Don't you track something?
Yes. And this is where most "privacy-first" tools quietly abandon the principle.
AppCrib uses PostHog for analytics, but it's consent-gated through Klaro. No cookies until you explicitly opt in. No tracking scripts load until you say so. Decline and nothing breaks. The tools work identically either way because they don't depend on a server connection to function.
When analytics are active, they answer one question: which tools do people actually use? We want to know whether to keep improving something or let it sit. That's the extent of it. No user profiles. No cross-tool tracking. No aggregate data sales.
Your actual tool data (the JSON you pasted, the image you stripped, the jq query you wrote) is never part of analytics. Can't be. It never reaches us.
What about local storage? Isn't that tracking?
Some tools save preferences to localStorage: theme choice, indent width, that kind of thing. It lives in your browser, on your device. We can't read it. We don't sync it. Clear it and you lose nothing that mattered.
Compare that to cloud sync, where your preferences live on someone else's server, tied to your account, profiled and cross-referenced with everything else you do. localStorage is the boring choice, and that's the point. Your preferences exist on the device where you set them and nowhere else.
Why does this matter more than you think?
Think about what people actually paste into free web tools. Production API keys. Database connection strings. Customer records during debugging. Internal config files. Medical data copied from a report to reformat. GPS-tagged photos of their home.
All of that has real consequences if it leaks. And "leak" doesn't require a dramatic breach. A server log gets backed up to an unsecured S3 bucket. A company gets acquired and the new owner has a different opinion about data monetization. A court order for server logs captures everything indiscriminately.
Client-side execution eliminates the entire category. You can't subpoena data that doesn't exist. You can't breach a server that never had it.
The only credible privacy guarantee is a structural one
We could write a beautiful privacy policy. Hire a lawyer. Put a padlock icon next to a "Your data is safe" banner and call it a day.
Instead, we built the tools so there's nothing to promise about. Static export. No backend. CSP headers that block unexpected connections. Consent-gated analytics. localStorage instead of cloud sync. The privacy story isn't in a legal document. It's baked into the architecture, and you can verify it yourself with a browser's DevTools.
Every tool on AppCrib works this way. Blank strips your photos without uploading them. jsonr formats your JSON without a server. Jqbin runs real jq locally via WASM. Your data stays on your device because the tool was built so it has nowhere else to go.
Not a promise. Just how it works.