Upload a file to a server-based converter and three things happen. Your file travels over the network to an IP address you did not control. A process on that server decodes it. Then, depending on the site's retention policy, the file sits on disk for anywhere from minutes to forever.
Do the same thing in a browser tab and the file never leaves RAM on your machine. The decoder runs inside a WebAssembly sandbox the browser engine enforces. The network is never touched.
This is not a policy difference. It is an architectural one. A server-based converter can promise to delete your files; a browser-based one cannot leak them because it never receives them in the first place.
The Architecture
Four layers make client-side conversion work:
Layer 1: File Access
When you drop a file into a browser tab, the DragEvent or <input type="file"> gives JavaScript a File object. A File is not the file's contents. It is a reference: a name, a size, a MIME type, and a method (file.arrayBuffer()) that reads bytes from disk into memory on demand.
Until that method is called, zero bytes have moved. The file sits on your filesystem. The browser's file picker is an OS-level dialog; the web page sees only the File object the user explicitly selected.
Layer 2: Format Detection
The first bytes of any file identify its format reliably. A JPEG starts with FF D8 FF. A PNG starts with 89 50 4E 47. A HEIC file contains an ftyp box with a heic or heif brand at offset 8.
Reading a file's header (the first 32 bytes, typically) is enough to confirm what it actually is, regardless of extension. This check runs before any decoder touches the pixel data. If the header does not match, the file is rejected immediately. No wasted CPU, no confusing error messages halfway through a decode.
Layer 3: Decoding
Raw bytes become pixels through a decoder. Which decoder depends on the format:
- JPEG, PNG, WebP, BMP: the browser ships native decoders for these.
createImageBitmap()hands the compressed bytes to the platform's codec (Windows Imaging Component on Windows, Core Graphics on macOS, Skia on Linux/ChromeOS) and returns raw pixel data. This path is fast, hardware-accelerated where the OS supports it, and requires no additional code. - HEIC: no browser except Safari ships a native HEIC decoder. Our converter bundles libheif, a C library, compiled to WebAssembly. The
.wasmbinary (~1.2 MB compressed) downloads once and caches. It decodes HEIF/HEIC files to raw RGB pixels entirely inside the WASM sandbox. - PDF: PDF.js (Mozilla's PDF renderer) renders each page to a canvas at the requested resolution. No server-side rendering. The PDF never leaves the browser.
Every decoder reads from memory and writes to memory. None open sockets. The WASM sandbox in particular cannot make network requests: the browser does not expose networking APIs to WebAssembly modules. Even if the C code called socket(), the sandbox would trap it.
Layer 4: Encoding
Raw pixels go into a <canvas> element's 2D context. canvas.toBlob() or canvas.toDataURL() calls the browser's built-in encoder for JPG, PNG, or WebP output. The encoder is platform-native code: the same code path your operating system uses to save screenshots.
The output is a Blob, an in-memory byte buffer. It gets handed to a download link or packed into a ZIP archive built in JavaScript. At no point does any byte touch a network socket.
What the Browser Enforces
Web pages run inside a sandbox the browser maintains at the engine level. This is not a polite agreement. It is enforced by process isolation:
Renderer process: the JavaScript engine, DOM, and WASM runtime live in a sandboxed process with no direct filesystem or network access. It communicates with the outside world through IPC to the browser process.
Site isolation: modern browsers put each origin in its own renderer process. Your files in file-convert-factory.org are invisible to JavaScript running on any other domain.
WASM sandbox: WebAssembly modules see a flat linear memory buffer and nothing else. No filesystem APIs, no fetch unless explicitly imported from JavaScript, no access to the DOM or other browser APIs. The worst a compromised WASM module could do is corrupt its own memory and crash the tab.
A server-side converter runs as a privileged process on the server's OS. It can read from disk, write to disk, open network connections, and spawn child processes. The security model depends on the server operator's competence and intentions. The browser sandbox depends only on the browser engine's correctness, and browser sandboxes are among the most heavily audited security boundaries in software.
What Server-Based Converters Do (and Do Not) Promise
Server-based converters are not inherently malicious. Many are run by well-intentioned teams. The problem is structural:
- The upload step is a copy. Your file now exists in two places. You control one copy. Someone else controls the other.
- Deletion is a promise. "We delete files after 24 hours" means trust the log line, the cron job, the backup system, and every employee with server access. None of this is verifiable from outside.
- Metadata travels with the file. Your photo's EXIF data (GPS coordinates, camera serial number, timestamp) is part of the file bytes. If the file is uploaded, the metadata is uploaded. Our EXIF privacy guide covers exactly what is in there and how to strip it. The short version: every converter on this site strips metadata because it decodes pixels and re-encodes them, dropping everything that is not image data.
- HTTPS protects the pipe, not the endpoint. TLS encrypts the upload in transit. It does nothing about what happens to the file after it arrives.
The privacy guarantee of a browser-based converter is narrower but stronger. It says: your files do not leave your device because there is no code path for them to do so. This is verifiable. Open the Network tab in DevTools while converting a file. You will see the WASM binary load once, then nothing. Zero bytes uploaded. No requests to /api/convert. No WebSocket traffic. The conversion happens entirely inside the renderer process.
Verifying This Yourself
You do not need to take anyone's word for it. Open Chrome DevTools (F12), switch to the Network tab, and convert a file on any tool page. The only network activity you will see:
- The page HTML, CSS, and JavaScript: loaded once on first visit.
- The WASM binary (for HEIC converters): loaded once, cached thereafter.
- Analytics requests (if you have not blocked them).
No file data leaves the browser. The Content-Length of every request is measured in kilobytes, not megabytes. This is independently verifiable by anyone who knows how to open DevTools.
The same cannot be said for a server-based service. You upload the file, you get a result, and you trust that the server deleted it.
Related Tools
Every converter on this site follows this architecture. The pipeline (drop, validate, decode, encode, download) runs identically across all 23 tools:
- HEIC to JPG · HEIC to PNG · HEIC to WebP
- JPG to PNG · JPG to WebP · JPG to ICO
- PNG to JPG · PNG to WebP · PNG to ICO
- WebP to JPG · WebP to PNG · WebP to ICO
- BMP to JPG · BMP to PNG · BMP to WebP · BMP to ICO
- PDF to JPG · PDF to PNG · PDF to WebP
- Image to Text (OCR): same client-side architecture, runs Tesseract in WASM
For the technical guts behind the WASM sandbox, see our WebAssembly explainer. For a deeper look at what metadata your photos carry, the EXIF privacy guide walks through reading and stripping it byte by byte.
