How on-device file tools work (and why nothing gets uploaded)

You are about to drop a signed contract, a folder of photos or a three-gigabyte screen recording onto a web page that promises nothing is uploaded, and you would like something better than a promise. This guide explains what happens between picking a file and the result landing in your downloads folder: which engines do the work, where the bytes live, why some jobs are fast and others slow, and how to check every claim with the browser’s own developer tools. You will also learn exactly what the one tool that does talk to a server can and cannot see.

What “nothing is uploaded” means, step by step

The classic online converter works in three hops. Your browser sends the file to a server with an HTTP POST; the server queues it, runs a converter and stores the result; you download it; a retention policy decides when the copies are deleted. Every hop is a place your bytes exist on hardware you do not control.

An on-device tool replaces all three hops with memory operations inside one tab. Opening the page downloads code — JavaScript and, for heavy jobs, a WebAssembly engine. When you pick a file, the browser hands the page a File object: a handle to bytes on your disk, exposed by the File API. The page reads it with file.arrayBuffer(), or in slices with file.slice(), and runs the engine on those bytes, usually in a Web Worker so the page stays responsive. The result is a Blob in memory, and “download” means the page creates a blob: URL for it and triggers a save — a copy from your RAM to your disk. Nowhere in that chain is a network request that carries the file.

The PDF merger is the simplest example on the site. It accepts only names ending in .pdf, keeps the merge button disabled until you have added two files, and lets you reorder them with the arrows. Merge & download loads each file with pdf-lib’s PDFDocument.load(await file.arrayBuffer()), copies every page into a fresh document with copyPages, serialises it with save() and downloads the bytes as merged.pdf. Pages are copied as objects, not re-rendered, so text stays selectable and images keep their resolution.

The engines, and why each one was chosen

The FFmpeg core is a 31 MiB .wasm file, over the 25 MiB per-file limit of the static host, so it ships as a 10 MiB ffmpeg-core.wasm.gz and is inflated in your browser with DecompressionStream. On video pages it is not fetched until your first click, keypress or drag — a visitor who bounces from a search result never downloads it.

One conversion, followed end to end

Take the MP4 converter. Its drop zone lists avi · flv · mov · mp4 · mpeg · ogg · webm · wmv & more. The moment you drop a file it is probed: mediabunny reads the primary video track’s dimensions and duration and asks WebCodecs canDecode() — can this browser, on this hardware, decode this codec? That answer decides which of two paths runs.

Path one: hardware codecs

If the answer is yes and the source is a container mediabunny can demux (.mp4, .m4v, .mov, .mkv, .webm, .3gp, .ts, .mts), frames are decoded and re-encoded by the device’s media block, not by software. A 4K source stays 4K, and the options dialog says so: “High-resolution source — converts at original size using your device’s hardware encoder.” Above 1.5 GiB, and only in Chrome or Edge, the page asks where to save before converting and streams the output to that file through the File System Access API, so the result never sits in memory as one buffer.

Path two: FFmpeg in WebAssembly

Everything else goes through ffmpeg.wasm with a command you could run on a desktop:

ffmpeg -i input.avi -c:v libx264 -preset superfast -threads 4 input_output.mp4

Picking a resolution appends -vf scale=-2:720,setsar=1:1; the compress tick adds -crf 23; mute adds -an. A source taller than 1088 pixels is capped to 1080p on this path and the dialog says: “High-resolution source — output is capped at 1080p for in-browser conversion on this device. Pick 720p for a smaller, faster file.” The exit code is checked, so a failed run throws ffmpeg exited with code 1instead of producing a truncated file. A target size in MB becomes a bitrate budget (bytes × 8 × 0.93 ÷ duration, minus 128 kbps for audio); an overshoot triggers one re-encode at a corrected bitrate, with x264’s strict -maxrate/-bufsize control as the final guarantee.

How to verify it yourself

1. Network tab. Open the developer tools (F12), pick Network, clear it, and run a conversion. You will see GET requests for engine files — /js/ffmpeg/ffmpeg-core.wasm.gz, /js/imagemagick/magickApi.js, /js/pdfjs/pdf.worker.min.mjs — and nothing else. Type method:POST into the filter box: the list is empty.
2. Airplane mode. Open a tool, click once so the engine loads, then disconnect and convert. A service worker keeps /js/, /_next/static/ and /css/ in a cache bucket named omd-runtime-<build id>, replaced on every site update; only the OCR models (omd-models-…, ~37 MiB) are kept across updates.
3. Console. Type crossOriginIsolated and press Enter. On /convert-to-mp4 it prints true; on /merge-pdf it prints false.

The exception: device-to-device sharing

Share Files is the one tool with a server-side piece. When you pick files it opens a WebSocket to wss://signal.onmydevice.app and gets a share code; the link and QR code point at /share-files#<code>. The receiver opens the same room, and a Cloudflare Worker relays the WebRTC handshake between the two sockets — offers, answers and ICE candidates — wrapped as { "type": "signal", "raw": "…" } without parsing them. What that Worker sees: the room code, two connections and their IP addresses, and the handshake blobs. What it never sees: file names, sizes, bytes or the PIN. It stores nothing, and the room ceases to exist when both sockets close. Each browser also sends one STUN request to stun.cloudflare.com:3478 to learn its public address.

After the handshake the file moves over a DTLS-encrypted data channel in 64 KiB chunks. The optional 4-digit PIN is checked over that same channel — three wrong entries lock the share — and not even the file list is announced until it matches. Chrome and Edge stream the chunks straight to a file or folder you pick; other browsers assemble them in memory. If no direct route forms within 20 seconds the page asks the Worker for short-lived relay credentials, and when a relay is in use it tells you: “No direct peer-to-peer connection was possible, so this transfer is falling back to a relay server.” The relay forwards ciphertext it cannot read; the large-file transfer guide covers the networking in more depth.

Where the limits come from

Speed follows the same logic. A hardware encoder is a dedicated chip that runs at many times real time and barely touches the battery; x264 in WebAssembly is software on four threads, so a ten-minute 1080p clip can take longer than ten minutes on a phone. The same file is therefore quick in Chrome on a laptop and slow in a browser that cannot decode it with WebCodecs.

The image compressor shows the image-side trade-offs. Its editor caps the working image at 4096 px on the long edge, because it holds several full-size copies of the bitmap and a 48 MP phone photo would exhaust a mobile tab. Saving re-encodes JPG, PNG or WebP at quality 0.72 and pulls any photo wider than 2560 px down to that edge; JPG is the default output because PNG has no quality knob. Typing a number into Max file size (KB) switches to a binary search over quality between 0.05 and 0.97, shrinking the dimensions by a quarter whenever even the lowest quality is too large, until the output is under the cap or the search gives up with cannot fit image under N bytes.

Cross-origin isolation in plain terms

The multi-threaded FFmpeg core shares one memory between its worker threads, and the browser only allows that — the SharedArrayBuffer type — when the page is served with two headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Together they put the document in a state called cross-origin isolation, which is what crossOriginIsolatedreports. The second header has a side effect: the browser refuses any cross-origin resource that has not explicitly opted in, and advertising and analytics scripts have not. So the 18 video and audio routes that need the headers carry no third-party scripts — not as a policy statement, but because they would be blocked. Isolation belongs to the loaded document, so every link into or out of those routes is a full page load rather than a client-side transition; that is why switching between a PDF tool and a video tool feels like a “real” navigation. Every other tool is served without the headers.

On-device versus upload-and-convert

What we do collect

Nothing about your files — no names, sizes, contents or hashes reach us. The site is not free of data collection, though. The hosting infrastructure keeps ordinary server logs (IP address, browser type, pages requested). Pages outside the isolated video and audio routes load Google AdSense, Google Analytics and Cloudflare Web Analytics; in the EEA, UK and Switzerland a consent message asks before advertising cookies are set, and the tools themselves set no cookies. We also record anonymous outcome events — a video conversion fell back to FFmpeg, a share failed with reason connection-failed — so we know which paths break; on isolated routes they wait in localStorage until your next visit to a normal page. The full statement is on the privacy policy page.

Common mistakes and how to read the errors

• Closing the tab mid-conversion.There is no server job to come back to; the work lived in that tab’s memory. Share Files shows the browser’s “Leave site?” prompt and holds a screen wake lock while bytes move, but cannot stop you.
• “Could not merge these files. One of them may be corrupted or password-protected.” pdf-lib can open an encrypted file but cannot copy its pages. Remove the password with the PDF unlocker first, then merge.
• A 3 GB AVI fails outright. AVI, FLV and WMV have no hardware path, so the whole file must fit the FFmpeg buffer. Trim it first; for MP4/MOV/MKV/WebM sources, use Chrome or Edge so the streaming path applies.
• “Could not read this image. The file may be corrupted or in a format this browser cannot decode.” The canvas, ImageMagick and heic2any all declined. A HEIC variant that fails gets its own message; export it from the phone as JPG.
• “This share link is no longer active — ask the sender to share the file again.” The sender closed their tab. Share links are live sessions, not stored files; both tabs must be open at once.
• “Couldn’t establish a connection between the two devices.” Usually one side is on mobile data behind carrier-grade NAT. Joining both devices to the same Wi-Fi gives a direct route without any relay.