In a sentence
Most tools run inside your browser, so the file never leaves your device. The tools that need a server, the AI tools and documents sent for signature go to servers in the European Union over encrypted connections, are kept only as long as this page says, and are never used to train anything. We hold no certification yet; this page says exactly what we do instead.
Where your files go
- Browser tools (merge, split, compress, edit, redact, sign your own PDF and the rest): the file is opened and changed by code running in your browser. Nothing is uploaded. You can unplug the network and they still work; Pro keeps them installed for offline use.
- Server tools (Office conversions, server compression, OCR on our servers, PDF/A, web and document printing, the PDF/A check, the developer API): the file is uploaded straight to a storage bucket of Cloudflare R2 restricted to the European Union, processed on a server we rent from Fly.io in Amsterdam, and the result is put back in the bucket for you to download. Each page says before you start that it runs on our servers.
- AI tools (Summarize, Chat with, Translate PDF): only the text of the pages leaves your browser, over our servers to Anthropic, PBC in the United States, per request. We keep no copy of it, and it is not used to train models.
- Sign requests: the document and the signed copies are kept in the same EU bucket until the request’s retention ends.
- Records (accounts, jobs, billing, sign requests, usage): a database run by Supabase in London, under the UK adequacy decision.
The site’s functions run in Dublin, Ireland; its pages are served from a content delivery network near you. The privacy policy names every company involved and the basis for each transfer.
How long things are kept
| What | Kept for |
|---|---|
| Files of a browser tool | Never stored by us: they stay in your browser. |
| Files and results of a server tool, Free | One hour after the job ran, or until you delete the job. |
| Files and results of a server tool, Pro | One day by default; the account can choose one hour, one day, a week or 30 days. |
| Files and results of an API job | Two hours by default; a job can ask for up to 24. |
| Documents of a sign request | 90 days after the request ended, then deleted; the audit record of a finished request is kept seven years without the document, so a signature can be checked. |
| Client workspace folders | Until the date set on the folder; the application deletes them, and a bucket rule of two years is the backstop. |
| A copy of your account data (export) | Seven days. |
| Nightly backups of the database | 30 days, encrypted before they leave the server with a key we hold offline. |
| Usage statistics | Visitor codes change daily and name nobody; 400 days. |
Deleting a job deletes its files at once. Deleting an account erases its records and files, keeping only what accounting requires. Bucket rules delete anything the application missed: jobs after 31 days, sign documents after 91, exports after 8, backups after 31, client folders after two years, unfinished uploads after a day.
In transit and at rest
- Every connection uses TLS; the site is on the HSTS preload list, so browsers never try plain HTTP. Uploads and downloads go to the bucket over signed links bound to one file, one size, one content type and fifteen minutes.
- The storage provider and the database provider encrypt what they hold at rest. Backups are encrypted by us before upload (age, X25519), with the private key kept off every server.
- Passwords are hashed with scrypt and checked against known breaches before they are accepted (five characters of a fingerprint leave, nothing else). Sign-in links, session tokens, signer links and API keys are stored only as hashes. Authenticator secrets are encrypted (AES-256-GCM) under a key derived from the application secret.
- Secrets live in the hosting environment, never in the repository.
Who can see a file
Nobody, in the ordinary course of things. Server tools run unattended; logs record a file’s size, tool, timings and result code, never its name or content. Access to the production systems is limited to the people who run the service, behind authenticator codes, and every administrative action is written to an audit log. We would open a file only to investigate abuse or at a lawful order, and the privacy policy says how we respond to those.
The application itself
- Every request that changes something must come from our own pages (origin checks on top of same-site cookies); a job that is not yours does not exist; options are validated by the same schemas on the API and the worker; file names are never used as paths.
- Web page to PDF resolves an address before fetching it and refuses private, local and metadata addresses, for every request the page then makes; an uploaded HTML file is printed with scripts off and nothing fetched.
- Pages carry a Content Security Policy with no third-party scripts; there is no ad network and no tracker. Statistics, when you allow them, are collected by our own code under a daily visitor code that names nobody.
- Dependencies are audited on every push (npm advisories and the OSV database); a newly published version waits a week before it can be installed; the code is scanned with Semgrep and the workflows with zizmor; every push runs the unit, engine, browser, accessibility and security suites, and nothing deploys unless they pass.
- Attempts at passwords, codes and links are counted in the database and rate-limited; accounts lock after ten wrong passwords in fifteen minutes; the public API is limited per key.
Accounts
Sign in with an email link, a password, a passkey, or Google; administrators must also use an authenticator app. The account page lists your sessions and lets you end them, exports your data, and deletes the account. We mail you when a new device signs in.
Reporting a problem
If you believe you have found a vulnerability, write to the address in /.well-known/security.txt. Please give us a reasonable time to fix it before publishing; we do not take legal action against good-faith research that stays within these pages and your own data.
Questions about this document can be sent to support@uvpdftool.com.
What we do not have yet
No SOC 2 report and no ISO 27001 certificate: we are a small company and say so rather than imply otherwise. No data processing agreement is published yet; ask us if your organisation needs one. The service is operated by UV ResearchLabs, a company established in Ireland; the terms name the governing law.