Security

Files are processed on your device

Every tool runs in your browser. The file bytes are never transmitted, so there is no upload to intercept, no server-side copy to breach, and no retention window to get wrong. This is a property of where the code runs rather than a policy we are asking you to trust.

It also bounds the impact of any compromise of our infrastructure. An attacker who took our web servers would gain the ability to serve you different JavaScript; they would not gain a store of anyone’s documents, because that store does not exist.

Input is validated before anything parses it

File type is determined by reading the bytes, never by trusting the extension or the MIME type your browser reports. Both of those are attacker-controlled, and a file named .pdf that is something else entirely is the oldest trick in this category.

Before a file reaches an engine we also read its header — within a hard byte cap — to establish page count and image dimensions, and reject anything beyond the limits. Byte size alone is not a safe measure: a 4 MB PDF can contain half a million pages, and a 40 KB PNG can decode to gigabytes of bitmap. Both pass a size check and then exhaust the machine.

These checks run in two places that do not trust each other: in your browser, and again beside the engine.

Engines and the supply chain

Processing engines are served from our own origin rather than a third-party CDN, with Subresource Integrity hashes recorded against each version. Serving executable code from someone else’s infrastructure into pages that handle legal documents is a risk we are not willing to take for a marginal caching benefit that browsers no longer provide anyway.

Engine licences are checked in the build. A build that binds a tool to an engine whose licence has not been approved fails rather than shipping.

Analytics boundary

Optional analytics scripts are not present in the initial document and are loaded only after an explicit analytics choice. The first-party analytics API independently checks the matching consent cookie before it will accept an event or create a visitor identifier.

Revoking consent disables future Google Analytics collection, expires accessible analytics cookies, and queues deletion of first-party event rows linked to the visitor identifier. The identifier cookie is cleared after deletion succeeds; a transient failure retains it as an HTTP-only deletion key for no more than 24 hours while bounded and future retries run. It cannot authorize new events after consent is denied. Analytics events never contain file bytes, names, extracted content, or generated output.

The parts that do run on a server

Saying "it all happens in your browser" would be a tidier page and a less honest one. The tools are client-side; the site around them is not entirely. Three routes accept something you typed and store it: the contact form, a tool request, and a vote on the request board. None of them accepts a file, and there is no upload endpoint anywhere on the site for one to reach.

What that means for you is bounded and worth stating plainly. An attacker who reached that database would find contact messages, tool requests and the email addresses attached to them. They would not find a document, a spreadsheet, an image or a video, because those were never sent. The privacy policy lists the exact fields each route stores.

What we do not claim

Client-side processing protects your files from us. It does not protect them from your own device: malware on your machine, or a compromised browser extension with permission to read page content, can see anything you open here, exactly as it can see anything you open anywhere else.

A watermark is a statement of intent, not a security control. A password removed from a PDF you own is removed for anyone who then receives that file.

Reporting a vulnerability

Write to security@tools-verse.com. Please give us a reasonable period to fix an issue before disclosing it publicly. We will confirm receipt, keep you updated on the fix, and credit you if you would like to be credited.

We are particularly interested in anything that would cause a file to leave a user’s device, anything that defeats the input validation described above, and anything that would let one page influence what another page executes.