How AtlasDocs converts files without sending anything to a server

What "100% in the browser" means in practice

When you merge two PDFs, extract the audio from a video or read text from a photo on AtlasDocs, the file doesn't travel anywhere. The browser downloads the program that does the work, and the work happens in your computer's or phone's memory. The result is generated there and saved straight to your device. There is no upload, no server queue, and no copy of your document sitting somewhere waiting to be deleted. The privacy page says that in one sentence; this article explains how it's possible.

The foundation is a technology called WebAssembly, which lets programs originally written for desktop computers run inside the browser. That's how well-known engines came to work in your tab: 7-Zip for compressed archives, FFmpeg for video and audio, Tesseract for recognizing text in images, SQLite for databases, and RAR reading. For PDF we use two open-source libraries written for the browser: one that edits the document and another, maintained by Mozilla, that draws the pages on screen.

Merging PDFs: the simplest case

The merge tool is a good example of the whole flow. You pick the files, set the order and click merge. The browser reads each PDF as a block of bytes, copies the pages into a new document and assembles the final file. None of that touches the network. On an ordinary computer, merging ten ten-page PDFs takes under a second. The same goes for split, rotate, compress, password-protect and the other PDF operations.

Reading text from an image: the heavy engine loads only when you ask

Recognizing text in a photo needs a large engine plus the language model. If it shipped with the page, the site would be slow for everyone, including people who only want to rotate a PDF. So each tool loads its own engine on demand, at first use. The home page weighs the same with or without the heavy tools. That's also why the first use of a video or text-recognition tool takes a few extra seconds: it's the engine download, once, which the browser then caches.

Video and audio: the whole of FFmpeg inside the tab

Extracting audio from a video, joining videos, changing the format or adding a watermark uses FFmpeg, the same program studios and streaming services use. The browser version runs in an area separate from the page, so the interface keeps responding while the video is processed. The limit here is device memory: a video of several hundred megabytes may not fit on a basic phone. When it doesn't fit, the conversion fails and the tool shows an error message; nothing is sent elsewhere to retry.

Compressed archives: reading RAR without installing anything

RAR is a closed format. Its license allows reading and extracting, but not creating RAR archives outside the official program. That's why AtlasDocs opens, extracts and converts RAR to ZIP or 7z, but doesn't produce RAR. The compression engines are hosted on the site itself, with backup copies on public content networks in case the first one fails. If you opened a RAR here, the engine came from our server; your file did not.

The two exceptions, stated on the tool itself

Two tools send the file to our server: converting Word, Excel and PowerPoint documents to PDF, and viewing those same documents. The reason is technical. There is, today, no browser program that opens Office files faithfully; what does it well is LibreOffice, which needs a server. In those two cases the file is converted and then discarded, and the tool shows a notice on screen before you send it. The other 138 stay on your device.

There are two more points of contact with the server, and neither sees your files. The help assistant sends the question you type to a language model, and only that. And the visit counter records only the page path, with no cookie, no stored IP address and no identification of a person.

How to check for yourself

1. Open any AtlasDocs tool on a computer and press F12 to open the browser's developer tools.
2. Click the "Network" tab and leave the request list open.
3. Send a file to the tool and run the operation until you download the result.
4. Look at the list: you'll see the tool's engine and the site's pages being downloaded, and no upload (POST) carrying your file's contents. The two exceptions do show the upload, as the on-screen notice says.

How the code is maintained

• The code is written in strict-mode TypeScript, about 76 thousand lines, and every change ships as a numbered version with published release notes.
• Every business rule lives in a module separate from the interface, so the same conversion can be reused across different tools.
• Each release runs 737 unit tests and 176 real-browser tests that open the pages, upload real files and check the result.
• A weight gate blocks a release if the home page or a tool gets heavier than the limit; Lighthouse on mobile scores between 94 and 97.
• The tools are available in Portuguese, English and Spanish, with the same interface in all three.

For videos and large files, prefer the desktop browser: it has more memory available than a phone, and the processing is still local.

If a tool sends your file to the server, it says so on screen before sending. No notice means the file doesn't leave your device.