Nothing about your file is sent anywhere. FileFlip downloads a conversion engine, the same C or C++ library a desktop app would install, compiled to WebAssembly, and runs it inside the browser tab you already have open. We converted a HEIC photo on convert HEIC to JPG and recorded every request the page made: the engine came down over a GET request, and not one request afterward carried the file.
What did WebAssembly change?
WebAssembly is a binary instruction format every major browser can run at close to native speed, which means a program written in C, like FFmpeg or ImageMagick, compiles once and runs inside a page instead of installing on a computer. Before it existed, a browser could not run that code at all, so a file converter had two options: install something, or send the file to a server and get a result back.
That second option is still what most online converters do. WebAssembly is why FileFlip does not have to. The engine runs in the same sandboxed process as the rest of the page, so it cannot reach the filesystem beyond the file you handed it, and it cannot open a network connection the page did not already make.
The engines, and what each one weighs
FileFlip does not ship one converter. It ships several, and downloads only the one your conversion needs. How FileFlip works lists all nine, and four are the ones doing the heavy lifting: ImageMagick for every image format, including HEIC to JPG, FFmpeg for the audio and video WebCodecs can't handle and for every subtitle conversion, MuPDF for reading and writing PDF and CBZ, and Pandoc for DOCX, EPUB, Markdown and 40 other document formats.
- MuPDF10.4 MB
- ImageMagick14.8 MB
- FFmpeg32.3 MB
- Pandoc58.6 MB
Uncompressed size of each engine's own WebAssembly binary, checked against the files FileFlip serves. ImageMagick is what a HEIC to JPG conversion downloads, highlighted because it's the one this page tested directly.
We checked ImageMagick's number ourselves rather than trusting the label. Converting our test HEIC file downloaded magick.wasm as a single GET request, and the response's ETag header encodes the file's exact size: 14,828,458 bytes, 14.1 MB. That matches the file on disk byte for byte, and the browser sends it gzip-compressed, so the actual transfer is smaller still.
That download only happens once. Every engine is served with a year-long immutable cache header, so the second HEIC you convert, or the hundredth, costs nothing more than reading the file itself.
WebCodecs, and when does the browser do the work itself?
For most audio and video conversions, FileFlip downloads nothing at all. MOV to MP4, most container swaps, and encodes to AAC or Opus run on WebCodecs, the browser's own hardware-accelerated encoder, through a library called mediabunny. Chrome, Edge, Safari and Firefox all ship WebCodecs already, so there is no engine to fetch.
FFmpeg's 32.3 MB only downloads when WebCodecs turns a conversion down. Chromium's own WebCodecs implementation encodes AAC and Opus but not MP3 or FLAC, so those formats fall through to FFmpeg, and so does every subtitle conversion, since WebCodecs has no concept of a subtitle track at all. FileFlip's own code tries mediabunny first for the target formats it can plausibly handle, and only reaches for FFmpeg's .wasm when mediabunny's Conversion.isValid check, or the conversion itself, comes back negative.
Either path runs on your machine. The difference is only whether the browser already had the encoder or FileFlip has to bring one.
How do you check this yourself in the network tab?
Open your browser's developer tools: press F12 on Windows or Linux, or Command, Option and I on a Mac, then choose the Network tab and clear the log. Convert a file, then read the list.
We ran exactly this against a 261 KB HEIC file to write this section, not just describe it. Here is what showed up:
| What we saw | What it means |
|---|---|
GET magick.wasm, 14,828,458 bytes |
The engine, downloaded once |
GET image.worker.js, 227,487 bytes |
The code that runs the engine in a background thread |
| Every other request | Page assets: fonts, scripts, styles |
| POST to Google Analytics, empty body | A page-view beacon. No file data, no request body at all |
Not one request in that list carries your file, and the one POST in the entire session has nothing in it. Sort the Network tab by size and your file will not be there at all. For a stronger check, convert one file so the engine is cached, then tick Offline in the same panel and convert another. FileFlip keeps working with no connection, which only makes sense if the work never left the tab in the first place.
What does this rule out?
A few things that a server-side converter can do and FileFlip cannot, because there is no server holding your file.
A file bigger than your browser tab can hold. FileFlip has no size cap of its own, but the engine and your file both live in the tab's memory. A desktop browser handles a multi-gigabyte video without trouble; a phone can kill the tab after a few hundred megabytes.
Picking the conversion back up on another device. There is nothing sitting on a server to resume from. Start the conversion where the file already is.
A result you can fetch later from a link. The output is handed to your browser's own download mechanism the moment it's ready. There is no stored copy to come back for, because storing it would mean a server had it.
None of these are limits an upload-based converter avoids for free. They avoid them by keeping a copy of your file somewhere else, which is the tradeoff this whole page is about.
Common questions
Is it actually safe to convert files online?
It depends entirely on whether the tool uploads your file, and the only way to know is to check, not to read a privacy policy. A server-based converter is only as trustworthy as its retention promise. FileFlip's claim is checkable in about thirty seconds with the network tab steps above, because there is no server-side copy for a policy to promise anything about.
Does FileFlip work without an internet connection?
Yes, once the engine for that format is cached. Convert one HEIC file to warm the cache, switch your browser to offline mode, and convert a second one. It finishes, because nothing after the first download needed the network.
Why does the first conversion of a file type feel slower than the rest?
Because that first run pays for the engine download, up to 58.6 MB for Pandoc's document formats. Every conversion after that of the same kind reads the cached engine instead, which is most of why it feels instant the second time.
Can the engine read files on my computer besides the one I converted?
No. WebAssembly runs sandboxed inside the page, with no filesystem access beyond the File object your browser handed it when you chose or dropped that one file.
Convert between them
FileFlip converts HEIC to JPG on ImageMagick and MOV to MP4 through WebCodecs where the codec allows it, falling back to FFmpeg otherwise, entirely inside your browser. Nothing is uploaded, there's no account, and the download you're waiting on the first time is the engine, not a queue. How FileFlip works covers every engine and every format pairing that runs like this.
How we measured this
- Engine sizes: read directly off the
.wasmfiles FileFlip serves frompublic/, cross-checked against the download figures on the how-it-works page, which are generated from the same build. - Network capture: loaded
/convert-heic-to-jpgon a local build of the site in a fresh, isolated browser context, uploaded a 261,177-byte HEIC file created with ImageMagick 7.1.2, and recorded every network request the page made from page load through a finished conversion. - Size verification: the
magick.wasmresponse's ETag header is a weak tag whose hex value decodes to 14,828,458, the exact byte count of the file on disk, confirmed withls -la. - Caveat: this is one conversion on one machine. The specific requests a different format triggers will differ, MOV to MP4 through WebCodecs downloads no engine at all, but the shape holds across every conversion on the site: a GET for the engine, then nothing that carries your file.