What actually happens when you drop a file
Your browser reads the file off your disk into memory using the standard File API —
the same one every website uses to show you a preview before an upload. The bytes
go to a Web Worker running in the same tab, which does the conversion and hands
back the result. A download link is made from that result with
URL.createObjectURL, which points at memory in your browser rather
than at any address on the internet.
At no point does a network request carry the file, because no such request exists in the code. There is no upload endpoint to send it to: the site is hosted as static files and has no backend at all.
How to check that, rather than believe it
Three ways, in ascending order of how convincing they are.
Watch the counter. Every tool page shows a live count of every
network request the page has made, with the full list of URLs. Convert something and
watch it stay still. It is wired into fetch, XMLHttpRequest,
sendBeacon and the browser's own resource-timing observer, so a request
made by any means would appear.
Open your own developer tools. Network panel, filter by Fetch/XHR, convert a file. Nothing appears. Ours is a convenience; yours is the browser telling you directly.
Turn the network off. Load a tool page, disable Wi-Fi or switch on aeroplane mode, then convert. It works. This is the one that settles it — a site that was uploading your file could not possibly still function.
What we cannot promise
Being precise about this matters more than sounding good. The page you are reading was downloaded over the network, so your browser contacted our host to fetch the HTML, the stylesheet, the fonts and the JavaScript. That means the host has the ordinary access-log record any web server has: your IP address, the page you asked for, your user agent. Nothing about your file, because the file was never in any of those requests.
The site carries advertising, and that is a real cost to the claim, so here it is in
the terms this page promised it would be. Ad scripts need network access of their
own. That means the Content-Security-Policy can no longer say connect-src
'self', and it was that one directive that made the promise unbreakable — the
browser used to forbid this page from contacting anything else, whatever the code
intended. It no longer does.
What did not change is the thing that matters: your file is not in any of it. It is never in a request, never reachable by a script that is not ours, and never leaves the tab. What changed is that you now have to check that rather than being able to take it as structurally guaranteed — so the counter on every tool page now itemises who each request went to, and turning your Wi-Fi off still converts.
Analytics is Google Analytics 4, page views only. No filename, no file size, no MIME type is ever in an event — one of those would make the headline claim untrue, and someone would rightly find it in the Network tab. In the EEA, the UK and Switzerland it does not run at all until you agree.
The real limits
We do not impose a file size cap, because there is no cost on our side to meter. What exists instead is a physical ceiling: everything is held in your device's memory at once, so a file too large for the tab to hold will fail.
Measured on real hardware, that is roughly ~2 GB in a desktop browser and ~400 MB on a phone. A phone that runs out of memory reloads the tab with no explanation, which is the worst failure we can ship, so where we can predict it we warn before starting rather than after.
Working offline
After your first visit the page shell and the conversion engine are cached by a service worker, so tool pages open and work with no connection at all. You can install the site as an app if your browser offers it, at which point it behaves like any other offline utility.
What each page downloads
Doing the work here means the code that does it has to arrive here. Most of the site needs almost nothing, because the browser already knows the formats: JPEG, PNG, WebP, AVIF and GIF are decoded by the browser itself, audio and video go through WebCodecs, and every text and data format is a few kilobytes of parser.
Four families are genuinely expensive, and it is worth being specific rather than vague about it:
- HEIC — 1.5 MB of code, about 510 KB compressed over the wire. HEIC stores an HEVC frame, HEVC is patent encumbered, and no browser outside Safari on Apple hardware will decode one. On Safari nothing is downloaded at all, because the operating system already has a licensed decoder.
- PDF — 2.1 MB of pdf.js, about 550 KB compressed, plus roughly 1 MB of outlines for the fourteen base fonts that most documents reference without embedding. Character maps for Chinese, Japanese and Korean text and the decoders for scanned images add up to another 2.5 MB, and are fetched only when a particular document turns out to need them.
- Archives — 600 KB of libarchive, about 330 KB compressed, which reads RAR, 7z, TAR and the rest.
- Spreadsheets — 650 KB of workbook parser, about 180 KB compressed, on the pages that read .xlsx and .xls.
Each is fetched when you open the page rather than when you convert, so the promise above holds: once the page has loaded, it needs nothing else. And each is fetched only on the pages that need it — a page that converts CSV to JSON never touches any of it.
Why the tools are built this way
Every large converter — CloudConvert, FreeConvert, Adobe, iLovePDF, Smallpdf — uploads your file to a server and converts it there. That architecture costs them real money per conversion, which is why they meter it: file size caps, daily limits, queues for free users, an email wall after the work is done.
Running the conversion in your browser makes our marginal cost per conversion zero. So the caps do not need to exist, and neither does the account system that enforces them. The privacy property is a consequence of that architecture rather than a promise about our conduct — which is the only kind of promise worth anything.
What it cannot do
Being static rules some things out permanently, and we would rather say so than pretend. Anything that needs to fetch a URL — converting a web page to PDF, taking a screenshot of a site, crawling a sitemap — is impossible from a browser because of the same-origin policy, and doing it with a proxy would mean running a server.
The specific things we refuse, and why, are worth naming because you will meet them:
- DRM-protected books. A Kindle book bought from Amazon is encrypted to the account that bought it. We detect that and stop. A converter that claimed otherwise would be circumventing the protection rather than converting a file.
- Scanned documents. A scanned PDF holds pictures of pages, not text. Getting words out needs OCR, which is character recognition rather than conversion and a genuinely different technology. We say so instead of returning an empty file.
- The pre-2007 Office formats.
.doc,.xls's sibling.pptand their relatives are binary OLE containers rather than XML. Re-saving as the modern format takes one step and then everything works, so we say that rather than shipping a second parser for a format on its way out. - Faithful page layout. Word, PowerPoint and PDF all decide their layout with engines we would have to reimplement. We rebuild the document — its text, headings, lists, tables and images — and say plainly on each page that the page itself is not reproduced.