How It Works

AinnoBox runs file processing tools entirely inside your browser. This page explains why that works, the technologies behind it, and how you can verify for yourself that your files never leave your device.

1. The traditional "upload, process, download" model

Most online PDF / image tools work like this:

1. your browser uploads the file via multipart POST to their server,
2. the server processes it with native tools (Ghostscript, ImageMagick, Pillow, etc.),
3. the resulting file is written to their disk (usually temporarily, hours to days),
4. you download the result.

All of that requires you to trust the operator: to believe they don't read, copy, train models on, or leak your file; to believe their backup policy is sound; to believe their employees and infrastructure are not compromised. For a casual meme that's fine. For your passport scan, your medical report, or a signed contract — less so.

2. The AinnoBox approach: run inside the browser

Modern browsers are powerful enough to do almost all of these jobs locally:

• WebAssembly (WASM)：lets us compile mature C/C++/Rust libraries (image codecs, PDF parsers) into bytecode that runs inside the browser sandbox at near-native speed.
• Web Workers：run heavy work on a separate thread off the main UI, so the page does not freeze.
• Canvas API：provides JPEG / PNG / WebP / AVIF encoding/decoding plus geometric operations (rotate, flip, resize).
• File API：lets the page read files you drag in — read-only, scoped to that single tab.

The tools are delivered as static assets (HTML, JS, WASM) from Cloudflare's global CDN edge. Once loaded, all processing happens in memory on your device.

3. Libraries we use

Every dependency is open-source, widely used and auditable. We do not invent our own crypto or codec algorithms.

4. Content Security Policy (CSP)

We ship strict CSP headers that restrict where scripts can come from and where data can be sent. This is the last-line defence against XSS and data exfiltration:

• script-src only allows: 'self', 'wasm-unsafe-eval' (required to run WASM), googlesyndication.com (ads).
• connect-src only allows: 'self', Plausible Analytics, AdSense.
• object-src 'none'
• frame-ancestors 'none' (cannot be embedded in iframes)
• upgrade-insecure-requests

The full CSP is delivered by Cloudflare's edge — you can verify it yourself via DevTools → Network → response headers.

5. Verify it yourself

You don't have to trust us — you can verify it yourself:

1. Inspect network traffic. Open DevTools (F12 / Cmd+Option+I) → Network tab, filter XHR/Fetch. Run any tool — you will not see any of your file content being uploaded.
2. Disconnect from the internet. After the page has loaded, switch to airplane mode or disconnect. The tools still work — proof that the entire pipeline runs locally.
3. Read the source. Right-click → View Source. The JS bundles are minified, but you can confirm that every external domain referenced is also in the CSP allow-list — no hidden server endpoint.
4. Inspect the CSP. DevTools → Network → pick any HTML request → Response Headers → find Content-Security-Policy.

6. What does get sent?

For full transparency: the following information leaves your browser (as it would for any website), but never includes your file content:

• Initial HTML / JS / WASM asset requests (from Cloudflare CDN)
• Plausible anonymous traffic stats (page URL, referrer, country-level country, browser family)
• Google AdSense ad fetches and impression metrics (subject to your cookie consent)

See the Privacy Policy for full detail.

7. Why is it free?

Operating costs are domain, CDN bandwidth and development time. We cover those by showing Google AdSense ads on the site — that is why there is no paywall, no login wall and no temptation to use your files as training data.