Every Tool You Need. Zero Uploads.

Why every tool here runs in your browser

AllTools is built on a simple architectural decision: nothing your browser can do should require a server. That's not a marketing promise — it's a property you can verify in 30 seconds. Open any browser's developer tools, switch to the Network tab, use any tool on this site, and watch what happens. No requests carrying your file data. No upload progress. No server processing. Your files don't leave your device because there's no endpoint to send them to.

How browser-based processing actually works

For image work, the browser's Canvas API does more than people realize. When you compress a 5MB photo using our Image Compressor, here's what actually happens: the browser reads the file directly from your disk via the File API, draws it onto an off-screen canvas, re-encodes it at a lower quality setting, and hands you back a new Blob. The original file never moves — only a derived version exists, briefly, in your tab's memory. The same pipeline handles resizing, cropping, and format conversion. Tools like Image Resizer and our PNG-to-JPG converter run on this primitive. No image is faster or smaller than one that didn't need to travel across the internet first, and your photo of a passport or contract or product mockup stays on the device that captured it.

PDFs and video are harder problems. They were designed for desktop software like Adobe Acrobat — manipulating their bytecode requires real compiler-grade work. WebAssembly changes the equation. Libraries like pdf-lib compile down to Wasm and run inside your browser tab at near-native speed. When you use PDF Merger to combine three contracts, or PDF Compressor to shrink a scanned document for email, you're running the same parsing logic professional tools use — just inside an environment your browser controls. For video, ffmpeg compiled to Wasm handles trimming, format conversion, and audio extraction. The cost is the initial library download (a few hundred kilobytes, cached after the first visit). The gain is that a confidential M&A document or an unreleased product video never appears on anyone's server logs.

Security tools live in a different layer entirely. Generating passwords, hashing files, or creating secure tokens requires cryptographically strong randomness — and there's exactly one correct API for it in browsers: crypto.getRandomValues(). Our Password Generator uses it. The common shortcut Math.random() doesn't qualify — it's a predictable algorithm meant for game logic and animations, not secrets. When you generate a 32-character password here, the bytes come from the operating system's secure random source, the same entropy pool that protects your HTTPS connections. The Hash Generator uses the Web Crypto SubtleCrypto API for SHA-256 and other functions. These aren't conveniences we built on top of a backend — they're capabilities the browser already has, exposed at the speed of local computation.

Why this matters for your privacy

There's a subtle but important difference between a privacy policy and a privacy architecture. A privacy policy is a document. It says what a company promises to do — or not do — with your data. It can change. It can be misread. It can be violated, sometimes accidentally through a server misconfiguration, sometimes deliberately after an acquisition. A privacy architecture is structural. It describes what a system can do, not what it promises. If files are never transmitted, no breach can leak them. If no account exists, no database can be sold.

For most people, the difference shows up in concrete moments. A legal team processing a draft M&A agreement. A doctor compressing patient X-rays for a colleague. A small business owner generating an invoice with bank details. A journalist redacting a source document. In each case, the file represents real risk if exposed — and "we promise not to look" is a weaker guarantee than "we built a system that can't look." GDPR compliance becomes trivial when zero personal data is transmitted. Information stays where it was created.

When you'd want a server-based tool instead

Browser-based tools aren't the right answer for everything. Three cases where a server-based tool serves you better.

First, AI model fine-tuning on your own data. The AI tools on this site run pre-trained models locally — they're powerful for inference, but they don't learn from your inputs. If you need a model trained on your specific documents or images, you need a server that holds them long enough to train.

Second, real-time collaboration. Two people editing the same document at the same time requires a shared source of truth somewhere. Browser-only tools can't sync between users — there's no server to coordinate.

Third, very large files limited by your device's RAM. A 5GB video on a mid-range phone will struggle; the same file on a workstation runs fine. Server tools borrow someone else's hardware to bypass this constraint.

We don't try to be those tools. We excel at the rest — and there's a lot of rest.