How Browser-Based File Conversion Works

When you hear "your file never leaves your browser," it might sound like a marketing claim. It isn't. It's a precise technical description of how modern browsers process files using a combination of web APIs that have matured over the past decade. Here's exactly what happens.

Step 1: Reading the file — the File API

When you select or drop a file, the browser's File API gives JavaScript access to it as a File object — a reference to the file on your local disk. The browser reads it into memory using a FileReader or the newer file.arrayBuffer() method.

This is a local read. No network request is made. The file data enters the browser's memory (RAM), exactly as it would if you opened the file in a desktop application. It stays there until you close the tab or navigate away.

Key point: a file read via the File API is no different from a desktop app opening a file from disk. The data never touches the network.

Step 2: Processing — WebAssembly, Canvas, and JavaScript

Once the file is in memory, the conversion logic runs. Different types of conversions use different browser technologies:

PDF operations (merge, split, rotate) — pdf-lib via JavaScript

pdf-lib is a pure JavaScript library that parses, creates, and modifies PDF files. It runs entirely within the JavaScript engine. Operations like merging two PDFs, rotating pages, or splitting a document all happen as in-memory array transformations.

PDF rendering (PDF to images) — pdfjs-dist via WebAssembly

Rendering a PDF page as a raster image is computationally heavier. PDF.js (Mozilla's open-source PDF renderer) is compiled to WebAssembly — a binary instruction format that runs at near-native speed inside the browser. It renders to an HTML canvas element. No server. No plugin.

Image operations (compress, resize, convert) — Canvas API

The HTML5 Canvas API gives JavaScript direct access to a pixel buffer. To resize an image, the browser draws it onto a canvas at the target dimensions. To compress it, canvas.toBlob() encodes the pixel data as JPEG or WebP using the browser's built-in codec.

Step 3: Keeping the UI responsive — Web Workers

JavaScript is single-threaded by default. Processing a 50 MB PDF on the main thread would freeze your browser tab. To prevent this, computationally intensive work is offloaded to a Web Worker — a background thread that runs JavaScript independently of the main UI thread.

The worker receives the file data, performs the conversion, and sends the result back. Web Workers are isolated: they cannot access the DOM, cookies, or the network unless you explicitly give them permission.

Step 4: Downloading the result

Once processing is complete, the result is an in-memory Blob — a chunk of binary data in your browser's RAM. To save it, the browser creates a temporary URL pointing to that Blob (URL.createObjectURL), and triggers a download via a synthetic click. The file goes directly from browser memory to your local disk. It never touches a server.

What about performance limits?

Browser-based processing is bounded by your device's available RAM and CPU. Modern browsers can comfortably handle files up to several hundred megabytes.

• A 100-page PDF is typically 5–15 MB — processed in seconds
• A 20 MP photo is around 60 MB uncompressed in memory — handled easily
• A batch of 50 images is processed sequentially, each fast

The sandbox guarantee

Every piece of code running on a web page — including WebAssembly modules — operates inside the browser's security sandbox. This means code cannot access your file system beyond what you explicitly grant, cannot make network requests unless initiated by the page's JavaScript, cannot access other tabs or applications.

You can verify that no network request is made during a conversion by opening DevTools (F12), switching to the Network tab, and watching while you run a conversion. You will see no outgoing POST request containing file data.

Open source transparency

The core libraries used by converteo.app are open source and auditable:

• pdf-lib — MIT license, auditable on GitHub
• PDF.js — Apache 2.0, developed by Mozilla
• libheif/libde265 — HEIC decoding, LGPL

Frequently asked questions

Does the browser need to download the conversion library?

Yes — once. JavaScript and WebAssembly modules are downloaded when you first visit the tool page and may be cached by your browser for subsequent visits. This download is the library code, not your file.

What happens to my file when I close the tab?

The browser frees the memory used by your file. Unless you explicitly saved the result to disk, no trace of the original file (or its converted version) remains.

Could the website's JavaScript secretly upload my file?

In principle, any JavaScript running on a page could make a network request. For converteo.app, you can open the Network tab and verify in real time that no file upload occurs. You can also use an extension like uBlock Origin to block all outgoing requests — the conversion will still work, because it requires no network connectivity.

Is WebAssembly safe?

WebAssembly runs inside the same security sandbox as JavaScript. It cannot access the file system, network, or operating system directly. All major browser vendors have invested heavily in WebAssembly security, and it has been standardized by the W3C since 2019.