How your files and account are protected

30 of our 48 tools run entirely in your browser using WebAssembly and native Web APIs. Your file is read into your browser's memory, processed there, and the result is handed back to you — nothing is ever transmitted anywhere. This isn't a privacy policy promise we have to honor; it's a structural fact, since there's no upload step in the code path for these tools at all.

Video tools, Office conversion, OCR, background removal, and a few other tools genuinely need server-side compute. For those:

• Files are uploaded over TLS and stored in isolated cloud storage, never a shared filesystem
• Every upload is validated by file signature (magic bytes), not just its extension, before any processing runs
• Uploads and results are automatically deleted no more than ~3 hours after processing (2-hour expiry, swept by an hourly automated job) — this doesn't depend on anyone manually remembering to clean up
• Office/PDF-repair/video processing runs in short-lived, network-isolated containers with a read-only filesystem — even a malicious file has nothing to persist to or escalate into

Passwords are hashed with PBKDF2-SHA256 (100,000 iterations, unique random salt per password) before storage. We never store your plaintext password, and no one at Documateo — including engineering — can recover it. If you sign in with Google, we never see your Google password at all.

Signed-in sessions use an HttpOnly cookie (invisible to page JavaScript, which rules out a wide class of cross-site scripting attacks against your login) with the Secure flag in production, meaning it's never sent over an unencrypted connection.

We never see or store your card number, UPI ID, or bank details — that data goes directly to Razorpay. Every payment confirmation is cryptographically verified twice, independently: once as an immediate check right after checkout, and again by Razorpay's own signed webhook call to our server. Neither path trusts a client-submitted "I paid" claim on its own.

Uploads are decompressed with a hard ratio ceiling, so a small file crafted to expand to gigabytes on decompression is rejected mid-stream rather than exhausting server memory.

Found a vulnerability? Email [email protected] with details — we take these reports seriously and will respond directly.