“Your files never leave your device” is the whole product, so it should not have to be taken on trust. This page explains exactly what happens to a file you drop here, what the architecture guarantees, and how to confirm all of it yourself in under a minute.
You pick a file
Selecting or dropping a file gives the page a File object — a reference to bytes on your disk, handed over by the browser. That is a local handle, not a copy and not a transfer. Nothing has moved anywhere at this point.
The engine loads
Only now does the page fetch the code for the conversion you asked for: a WebAssembly decoder, pdf.js, or nothing at all if the browser can already do the job. This is the last network request involved, and it is the page downloading code — not your file uploading.
The work happens in a Web Worker
Your file’s bytes are read into memory and passed to a background thread, which decodes, transforms and re-encodes them using WebAssembly and your browser’s own image and document engines. Your CPU does the work. The tab stays responsive because none of it runs on the main thread.
The result comes back as a Blob
The output is a Blob in memory. Clicking Download creates a temporary local URL for it and saves it to your disk. Downloading all creates a zip, also in the browser. At no point is there a server involved in producing your file.
Everything is released
Temporary URLs are revoked, buffers are dropped and workers are terminated when you clear the list or leave the page. Close the tab and every trace of the file is gone from memory.
Three checks, in increasing order of how conclusive they are. None of them require trusting anything on this page.
Press F12 (or ⌥⌘I on a Mac) to open developer tools, choose Network, then convert a file. You will see requests for the page’s own scripts and, on some tools, a WebAssembly decoder. Every one is a GET to this domain. There is no POST, no PUT, and no request carrying your file’s bytes — sort by size and the largest thing going out will be a few hundred bytes of headers.
Load a tool, convert one file so its engine is cached, then switch off Wi-Fi or set the Network tab to Offline. Convert another file. It still works — because there was never a server in the loop. A tool that uploaded could not do this, and no amount of privacy copy can fake it.
The strongest check, because it does not depend on what the page happens to do today. This
site sends a Content-Security-Policy containing
connect-src 'self',
which instructs your browser to block any network request from this page to
another origin. It is not a promise we make; it is a restriction we place on ourselves
that your browser enforces. Check it from a terminal:
curl -sI https://quietfiles.com/ | grep -i content-security-policy
The same header sets form-action 'self'
and restricts img-src,
closing the two other routes by which a page could smuggle data off a device.
We would rather state this plainly than claim your files are “100% secure”, which is not a claim any website is in a position to make.
A service worker caches the site’s pages, styles and core code the first time you visit, so QuietFiles opens and runs without a connection. Each tool’s processing engine is cached the first time you use that tool — a decoder can be several megabytes, and downloading every one of them up front to a phone would be a worse trade than fetching one on demand.
So: once you have used a tool, it keeps working offline. Before that, opening it needs a connection just long enough to fetch the engine. We would rather say that precisely than advertise blanket offline support that a first-time visitor would not actually get.
The Content-Security-Policy header. Its connect-src directive is set to "self", which means the browser refuses any network request from this page to another origin — not as a policy we follow, but as a rule the browser enforces on us. Adding an upload would mean visibly weakening that header, which anyone can check with a single curl command.
Cloudflare Web Analytics, which is cookieless, sets no identifiers, and does not follow you across sites. It reports page views to this site’s own domain. It never receives file names, file contents, file types, sizes, or anything derived from them — it cannot, because the file never leaves the tab and the analytics script has no access to it.
They are served from this site as static files, like the rest of the page. libheif (for HEIC) and pdf.js are open-source projects compiled at build time and shipped alongside the HTML. They run inside the browser’s WebAssembly sandbox and, like everything else on the page, are bound by the same Content-Security-Policy.
No. Files live in the tab’s memory for as long as the tab is open and are gone when it is closed or the page is reloaded. No file, file name, or anything derived from one is ever written to local storage, IndexedDB or a cookie. Two things do persist: the app itself, cached so it works offline, and — only once you use the theme switch — the single word “light” or “dark” in local storage.
That phrase is not one we will use, because it is not something a website can promise. What the architecture guarantees is narrower and checkable: your file is not transmitted to us or to anyone else. It says nothing about the security of your own device, your browser, or anything else you have installed — which is exactly where the file stays.