File privacy and retention
Understand browser-local checks, server processing, temporary storage, and anonymous processing totals.
Updated
Uploading a document to a web service is a decision, and this page gives you the facts to make it rather than a reassurance. Some AttachReady tools never upload anything. Others must, and those files are temporary. The sections below say exactly which is which, how long anything is kept, and what the numbers on the homepage actually count.
Where your file goes
| Operation | Does your file leave the browser? | What is kept afterward |
|---|---|---|
| Preflight and rule checks | No | Nothing |
| Local image inspection and compression | No | Nothing |
| Format conversion, image-to-PDF, PDF compression, merge, split, rotate | Yes, to the processing service | A result artifact, downloadable until it expires |
| Submission package | Yes | A ZIP artifact, scoped to your account |
| Stored account upload | Yes, when you upload it | The input file, scoped to your account |
Everything in the first two rows happens where the file already is. Nothing is transmitted for those operations, not even metadata. Everything in the remaining rows requires an upload.
The server path, step by step
When you run a server-side tool, the file is uploaded to private object storage, processed, and the result is written back as an artifact. Guest results return straight to the browser and are never saved as account uploads or job history. Account inputs and artifacts are stored temporarily and are scoped to the account that created them; API keys use the same ownership check, so one account's key cannot read another account's files.
Decide per file, not per service. A passport scan and a screenshot of a layout problem are not the same risk. Do not upload material you have no permission to process — if your employer or client restricts where their documents may go, that restriction applies here too.
How long anything is kept
Tool inputs and generated artifacts expire 24 hours after creation. Expiry is enforced at the API level: once a file is past its expiry, lookups, processing requests and downloads are all rejected. There is no way to extend it and no way to recover an expired artifact.
Physical deletion is a separate event from expiry, and the two do not happen at the same instant:
- The access layer stops serving the file at the 24-hour mark — this part is exact.
- A cleanup job runs every 15 minutes and deletes expired objects in batches of 100.
- Storage-level lifecycle rules provide a two-day fallback for anything the cleanup job could not remove, for example if metadata was cleared first.
- A transient storage failure leaves the record in place so the deletion can be retried rather than silently skipped.
In practice a file is usually gone from storage within 15 minutes of expiring, and is guaranteed to be gone within two days. So "expires after 24 hours" means access ends at 24 hours; it does not mean the bytes are shredded at that exact second. Download anything you need well before the deadline, and keep your originals somewhere else entirely — this is not a backup service.
Ordinary account assets such as avatars are not governed by this 24-hour tool TTL.
What the homepage counter records
The public figure records successfully processed input-file occurrences on the server. The unit is an occurrence, not a person and not a distinct file:
| You do this | The counter goes up by |
|---|---|
| Merge three PDFs into one | 3 |
| Convert two images into a single PDF | 2 |
| Process the same photo twice, both successful | 2 |
| Run a browser-local check | 0 |
| Retry a failed or cancelled job | 0 |
| Poll a job's status repeatedly | 0 |
| Replay an identical job under the same idempotency key | 0 |
What it does not record is worth stating just as plainly. The counter holds no file content, no filenames, no email addresses and no IP addresses. It cannot be tied back to a person, and it survives account and file deletion, because deleting an anonymous number would change a historical total without telling anyone anything. It counts from the moment collection was enabled; no earlier totals were invented to make the site look busier.
Two honest caveats. The displayed numbers are cached briefly, so they can lag the real count by a short interval. And if guest statistics fail to write, the download still completes — the user's job takes priority over the bookkeeping — which means the total can undercount. Read it as a lower bound on real activity, not an exact ledger.
What we do not claim
AttachReady is not end-to-end encrypted: files are readable by the processing service while a job runs, which is unavoidable if the service is to transform them. There is no separate virus-scanning quarantine zone, and no promise of one. Processing happens on infrastructure we operate and on a self-hosted media service we operate; there is no third-party conversion vendor in the path. If a specific compliance guarantee matters to you, ask before you upload rather than assuming.
Getting in touch
For access, correction or deletion requests, email support@attachready.com. The privacy policy covers the wider account and service policy, including what happens when you delete an account. Please do not send passwords, identity documents or confidential attachments in a support email — a minimal sample that reproduces the problem is more useful and less risky.