How this works
Every other file converter asks you to upload your document to a server you have never heard of. damnfiles does the work on the machine you are already sitting at. Here is exactly how, and where it gets hard.
The whole trick
The engines that convert files — pdf-lib, the browser’s own image codecs, fflate — are compiled to WebAssembly and shipped as static assets. Your browser downloads them once, then runs them locally on bytes that never leave your device. There is no upload endpoint in this product. Not a private one, not a temporary one. There is nothing to breach because there is nothing there.
You can verify this yourself in about ten seconds: open your browser’s developer tools, switch to the Network panel, and run any tool. You will see the engine download once, and then silence.
What that buys you
- No size limit. Nothing is uploaded, so there is no upload cap. The ceiling is your device memory, which on a desktop is far above what free converters allow.
- No queue. You are not waiting behind other people’s jobs on a shared server.
- It works offline. Install damnfiles from your address bar and every tool you have opened before keeps working on a plane.
- No account. There is no per-conversion cost for us to recover, so there is no reason to make you sign up.
What it costs you
Honesty first: the browser is not always the best place to do this work, and pretending otherwise would make this page marketing rather than documentation.
- Your device does the work. A ten-year-old laptop will be slower than a data centre. For most tasks you will not notice; for a large video you will.
- Phones have much less headroom. A mobile browser tab gets a fraction of the memory a desktop one does, so very large files can fail there and succeed on a laptop.
- Some tools are genuinely hard. 15 of the 150 tools listed here do not have a working engine yet. Their pages say so plainly instead of pretending.
Where we are
135 of 150 tools work today. The rest are listed because people search for them and deserve a straight answer about whether they exist yet, rather than a page that wastes their time. A tool ships when it genuinely works locally — never before.
The four hard problems
Video, and the 31 MB question
Video works — ffmpeg is compiled to WebAssembly and served from this site, so your footage never moves. The honest cost is a 31 MB one-time download the first time you open a video tool, and encoding that runs at your laptop’s pace rather than a render farm’s. For a two-minute clip that is fine. For an hour of 4K it is not.
Office documents
A PDF describes where marks sit on a page; a Word file describes a document’s structure. Going between them means inferring structure that was thrown away. We do reconstruct it — you get editable paragraphs and heading styles — but images, exact column positions and table borders do not survive, and every tool page says so.
HEIC and camera RAW
These lean on the browser’s own decoder. Safari and recent Chrome on macOS read HEIC natively; elsewhere they cannot, and RAW has a different variant for every camera maker. When your browser cannot decode a file, the tool says so plainly instead of writing something broken.
Anything that needs a big model
Recognition already ships: about 7 MB of OCR assets are served from this site, so scanned documents are read on your device and nowhere else. Background removal and speech-to-text need their own models, and each is another large download to justify before it earns a place here.
If a tool cannot be done locally
Then it does not ship. There is no “upload it to our server instead” escape hatch, because the moment one exists the promise on the front page stops being true. A smaller catalogue that means what it says is worth more than a bigger one that does not.