How LivePhotoTools Works (FFmpeg in Your Browser)
LivePhotoTools converts, extracts, and builds Live Photos entirely inside your browser tab. There's no server doing the work, no account to create, and nothing leaves your device. This page explains exactly what runs where, how to verify the "nothing is uploaded" claim yourself, and where the in-browser approach has real, honest limits.
What actually runs when you convert a file?
Everything runs client-side. When you drop a HEIC, .MOV, or .livp into a tool, your browser loads a copy of FFmpeg that's been compiled to WebAssembly (WASM) and runs the decode, transcode, and repackaging steps on your own CPU. The output file is generated in memory and handed back to you as a download. No frame of your photo touches a remote server.
WebAssembly is a portable binary format that runs near-native speed inside the browser sandbox. FFmpeg — the same engine behind most desktop video tools — is compiled to that format (commonly called ffmpeg.wasm) and executes against your file using your machine's RAM and processor. The heavy lifting for a Live Photo to video conversion or HEIC to JPG is HEVC and HEIF handling, and that's exactly what this WASM build does locally.
A few operations don't even need FFmpeg. A .livp file is just a ZIP container holding a HEIC/JPEG still and an HEVC .MOV, so extracting the still or the motion clip is partly a matter of unzipping in the browser. (For the underlying container details, see the Live Photo format reference.)
What does "nothing is uploaded" actually mean?
It means your files are never transmitted off your device. The page sends no POST/PUT request containing your image or video, stores nothing in a remote database, and keeps no copy after you close the tab. The only network traffic is loading the page and, once, the conversion engine itself.
This is a meaningfully different privacy posture from typical "free online converter" sites, where you upload the file to a server, the server processes it, and you download the result. In that model the operator briefly (or not so briefly) holds your photo. Here, the processing happens in the same sandbox as the web page, so the file's lifecycle stays on your hardware.
How can I verify nothing is uploaded?
Open your browser's DevTools, go to the Network tab, then run a conversion and watch the requests. You'll see the page assets and a one-time engine download, but no request that carries your file's bytes as an upload. If a tool were uploading, you'd see a large outbound request the moment you add your file.
Step by step:
- Press F12 (or right-click → Inspect) and select the Network tab.
- Optionally check Disable cache and clear the log.
- Add a file and start the conversion.
- Inspect the requests. Look at the Size and request Type / Method columns.
What you should and shouldn't see:
| You should see | You should NOT see |
|---|---|
| Initial page/script/style loads | A multi-MB POST request fired when you add your file |
A one-time .wasm engine download (first use) | Your filename or image bytes in any request payload |
| No outbound request when the actual conversion runs | A "processing on server" round-trip per file |
This is the honest, checkable version of "private." You don't have to trust a marketing claim — the absence of an upload request is visible in a tool that ships with every browser.
Why does the first conversion download a ~30MB engine?
Because FFmpeg compiled to WebAssembly is a real, full-featured binary, and the browser has to fetch it before it can run locally. That's a one-time download of roughly 30MB (give or take, depending on the build), and it's cached afterward — so the first conversion in a fresh session feels slower than the ones that follow.
A useful way to think about it: a server-side converter ships your file to where the software already lives. An in-browser converter ships the software to where your file already lives. The ~30MB is the cost of moving the engine once, in exchange for never moving your data at all. After it's cached, subsequent conversions skip that download entirely.
Do I need an account, and what about my data?
No account, no sign-in, no email. Because files are processed locally and discarded when you close the tab, there's no user data to store and nothing to log in to. There's also no watermark on output and no server quota deciding how many times you can use the tool.
To be clear about what this does and doesn't imply:
- No upload does not mean "no internet" — you still need a connection to load the page and the engine the first time. Once cached, many tools can run offline.
- No account means we can't and don't tie conversions to an identity.
- No watermark / free is a property of doing the work locally; there's no server cost to recoup per file.
What are the honest limits?
The in-browser model trades a server's predictable horsepower for your device's. That brings two real constraints worth stating plainly.
Large files are bounded by your device's RAM. FFmpeg-in-WASM decodes frames into memory, and the browser tab has a finite memory budget (especially on mobile or 32-bit contexts). Very large or very long videos can be slow, or can fail outright on a low-RAM device, where a desktop app with disk-backed processing would succeed. Converting a long clip into a Live Photo is more demanding than extracting a single still JPG.
HEIC decoding depends on your browser and OS. In-browser HEIC handling relies on either the WASM decoder or the browser's native support, and some Windows/Chrome setups simply can't decode HEIC because Windows lacks an HEVC/HEIF codec by default. If a HEIC preview fails to render, that's usually an OS-codec gap, not a bug in the tool. The HEIC guide covers when you'll hit this and how to add the Windows extensions.
Some things genuinely require iOS. We can generate a valid .livp or a wallpaper-ready file in the browser, but installing a working Live Photo into your iOS photo library, or setting one as a Lock Screen wallpaper, has to happen on the device itself. A browser or PWA can produce the files; it can't make iOS treat them as a native Live Photo. That's a platform boundary, not something any web tool can engineer around.
The short version
LivePhotoTools is a local toolkit dressed as a web page: FFmpeg compiled to WebAssembly does the conversion on your CPU, your files never leave the tab, and you can confirm that yourself in the Network tab. The costs are a one-time engine download and a dependence on your device's RAM and your browser's codec support — limits we'd rather state up front than paper over.