Security & Privacy Architecture
How every tool keeps your files on your device — the libraries we use, the network calls we make, and the exact steps you can take to verify it yourself.
The promise in one paragraph
When you drop a file into any WebToolVerse tool, that file's bytes are read from your local disk into your browser tab's memory and processed there. The result is offered back as a download. No part of the file's content is ever sent to our servers, to any third party, or anywhere else. The only thing that flows over the network is the same thing that flows for any normal web page: HTML, CSS, JavaScript, and a handful of analytics requests that carry no file data.
This page documents how that's actually implemented — which libraries do which jobs, what the browser is doing at each step, and how to confirm the claim by watching network traffic yourself.
How each category actually works
Every tool category is implemented with a specific open-source library running entirely in the browser. These libraries are bundled with the site and execute as JavaScript or WebAssembly on your device — they make no network calls of their own.
PDF tools
pdf-lib 1.17, @cantoo/pdf-lib 2.6, pdfjs-dist 4.8
Every PDF tool — merge, split, compress, password-protect, watermark, rotate, flatten, repair, sign, organize, edit metadata — uses pdf-lib (or its actively-maintained @cantoo/pdf-lib fork) for write operations and pdfjs-dist (Mozilla's PDF.js engine) for reading and rendering. The file is loaded as an ArrayBuffer via the standard FileReader API, mutated in memory, and returned as a Blob the browser exposes as a download. Encryption uses AES-256 from pdf-lib's built-in crypto path. Nothing in this pipeline touches the network.
Image processing
browser-image-compression 2.0, Canvas API, heic2any 0.0.4
Compressors and converters use the browser's built-in Canvas API to decode and re-encode images. browser-image-compression handles quality tuning, downscaling, and EXIF preservation/stripping in a Web Worker so the main thread stays responsive. HEIC → JPEG uses heic2any, which is a libheif WebAssembly build. Background removal is handled separately by an AI model (next item).
AI image features (Background Remover, Image Enhancer, OCR)
@imgly/background-removal 1.7, @huggingface/transformers 4.2, ONNX Runtime Web
Background removal runs the RMBG-1.4 segmentation model via ONNX Runtime Web — a WebAssembly build of Microsoft's ONNX Runtime. The model (~44 MB) is downloaded once on first use, cached by your browser, and then runs in a Web Worker entirely on your device. Image OCR uses Tesseract.js, also a WebAssembly port. Both genuinely run AI inference locally — no API call, no model server.
QR codes
qrcode 1.5 (generation), jsqr 1.4 (scanning)
QR generation produces static codes — your data is encoded directly into the code's pixel matrix, with no hosted redirect URL. The qrcode library outputs both PNG (via Canvas) and SVG. QR scanning uses jsqr to read QR codes from images, also in-browser. Because the codes are static, they never expire and there is no third-party service we could shut down later.
Developer tools (JSON, XML, regex, JWT, Base64, hashes)
Native JavaScript, crypto-js 4.2, bcryptjs 3.0
JSON / XML / YAML formatters use the browser's native parsers plus js-yaml (4.1) and js-beautify (1.15) for pretty-printing. Regex testing uses the native RegExp engine. JWT decoding parses base64url segments in JavaScript — the token never leaves your browser, which matters when the token is a real access token. Hash generation uses the SubtleCrypto API for SHA family and crypto-js for legacy algorithms. Password hashing uses bcryptjs (a pure-JS bcrypt) so it runs locally too.
Text and document tools
marked 18, diff 9, docx 9.6, mammoth 1.12
Markdown rendering uses marked. Text diffing uses the diff library. Word-document round-trips use docx and mammoth — the .docx file is parsed and modified entirely in the browser. Nothing in these pipelines reaches a server.
Other (passwords, GIF, screenshots, etc.)
Web Crypto API, gifenc 1.0, html2canvas 1.4
Strong-password generation uses crypto.getRandomValues — the browser's cryptographically secure RNG. GIF making uses gifenc, a fast in-browser GIF encoder. Screenshot beautifier uses html2canvas to render a DOM region to a Canvas. All in-browser.
What we do send (and why)
For full transparency, here's every network call WebToolVerse makes during a typical session. None of these carry the contents of any file you process — they exist to load the page and let us catch bugs.
Page assets
What: HTML, CSS, JavaScript bundles, fonts, and icons.
Why: Served from our own infrastructure (Vercel). Standard for any website. Cached aggressively so repeat visits are near-instant.
Google Analytics 4
What: Page views, session duration, country-level location, referrer, screen size.
Why: Tells us which tools people actually use and on which devices. Configured without User-ID, without ad personalisation, and with IP truncation. No personally identifiable information.
Sentry (error reports)
What: Stack traces and browser metadata when a JavaScript error occurs.
Why: Lets us see crashes in the wild and fix them. Sentry's SDK is configured to scrub URL parameters and form values — the file's bytes are never inside the page's URL or form state, so they cannot be captured here either.
If you block these with a content blocker, the tools still work — every transformation runs in JavaScript bundled with the page, so analytics and error reporting are non-essential to functionality.
How to verify this yourself
You don't need to take our word for it. Modern browsers ship with a Network inspector that shows every HTTP request the page makes — including who initiated it and what payload it carried. Here's the five-minute audit:
- 1.Open any tool, e.g. /pdf-merger. Don't process anything yet.
- 2.Open DevTools — press F12 on Windows/Linux or Cmd-Option-I on macOS. Switch to the Network tab.
- 3.Click 'Fetch/XHR' to filter to data requests. Optionally check 'Preserve log' so requests aren't cleared on navigation.
- 4.Click the Clear button (🚫) in the Network panel to start with an empty log.
- 5.Drop a real file into the tool and run the operation. Watch the Network tab as it runs.
- 6.Click any request to inspect its Headers and Payload. The only requests that should appear are: analytics pings (small JSON, no file data) and possibly an AI model download on first use of an AI tool. No request should carry your file's bytes — and you can confirm by checking the request size column, which will never approach your file's actual size.
Pro tip
Compare with a competitor: open Smallpdf or iLovePDF in another tab, run the same operation, and watch the Network panel. You'll see a multi-megabyte upload request with your file as the payload, followed by a similar-sized download for the result. That's the difference between “client-side” and “upload to our servers.”
The browser security model we rely on
Client-side processing is only as private as the environment running it. WebToolVerse depends on three browser guarantees:
Same-origin isolation
JavaScript loaded from webtoolverse.com runs in an isolated context. Code from other origins (including any embedded third-party iframe) cannot access the main page's memory, including any file your tool is processing.
Sandboxed file API
The File API gives a tab read-only access to a file you explicitly select — it cannot enumerate your filesystem or read other files. The file's bytes exist only inside the tab's memory for as long as you keep the page open.
Transparent network layer
Every HTTP request a tab makes is visible to you in DevTools. There is no hidden side-channel by which a script could exfiltrate data without showing up in the Network panel.
Known limitations
Honest documentation includes the boundaries:
Frequently asked questions
What does 'client-side processing' actually mean?
Every transformation — PDF merging, image compression, QR generation, background removal — runs as JavaScript or WebAssembly inside your browser tab. The file's bytes are read from your local filesystem into the tab's memory using the standard File API, processed in-memory by the appropriate library, and written back to a download link using a Blob URL. At no point is the file's content sent over the network to our servers or to any third party.
How is this different from 'we don't store your files'?
Many tools claim 'files are deleted after 60 minutes' or 'we don't keep your files.' Those tools still upload your file to a server, where it sits during processing and during whatever retention window they choose. WebToolVerse uploads nothing. There is no server-side handling of your file at all. The distinction matters for legally sensitive material, photos containing people, and anything subject to data residency requirements.
Then what does WebToolVerse send to its servers?
Only what's needed to load the page and operate the site: HTML, CSS, JavaScript bundles, fonts, and icons. Plus anonymised page-view analytics (Google Analytics) and runtime error reports (Sentry). None of these include file contents. Each is covered in detail below.
Can I verify this myself?
Yes — open Chrome DevTools (F12 or Cmd-Option-I), switch to the Network tab, then load a tool and run an operation. Filter by 'Fetch/XHR' to see network calls. You'll see analytics pings; you will not see any request carrying your file's bytes. The Verification section below walks through it step by step.
Does using a tool work offline?
Most tools do, after the first load. WebToolVerse is a Progressive Web App — a service worker caches the page assets the first time you visit, and subsequent loads pull from cache. Tools that don't need a model download (like JSON formatting or PDF merging) work fully offline. Tools that download an AI model on first use (Background Remover, Image OCR) require an internet connection that first time, then run locally afterwards.
Are AI features really running locally?
Yes. The Background Remover uses the RMBG-1.4 segmentation model compiled to ONNX and executed via ONNX Runtime Web (a WebAssembly build of ONNX Runtime). The model file is ~44 MB, downloaded once and cached by your browser. Inference runs in a Web Worker on your device — typically 2–8 seconds per image depending on hardware. Image OCR uses Tesseract.js (a WebAssembly port of Tesseract) the same way.
What happens when I'm using Incognito / Private Browsing?
Tools work the same. The service worker and any cached AI models are scoped to that private session — they'll re-download on the next private session. Analytics cookies behave according to your browser's private-mode rules (usually scoped to the session and discarded when it ends).
What if a third-party script gets compromised?
We load Google Analytics and Sentry from their official domains. These are the same scripts used by millions of sites; a compromise would be a major industry-wide event. Even so, those scripts have no access to your file data — file processing happens in libraries we bundle directly, and the file bytes never leave the page's JavaScript memory. Sub-resource integrity (SRI) is enforced on the bundled libraries.