Building a 100% Client-Side HEIC to JPG Converter: Zero Servers, Zero Uploads

Every time I Airdrop photos from my iPhone to my Windows machine, I run into the same annoying problem: .heic files. They don’t open natively on most Windows photo viewers, and converting them is a massive pain.

When I looked for online converters, I was shocked by how sketchy they were. Most of them required me to upload my private photos to their servers, limited me to 5 files per batch unless I paid, or spammed me with intrusive ads. As a developer, I knew there had to be a better, more secure way to handle this. Why send megabytes of private image data to a remote server when our modern browsers have more than enough computing power to do it locally?

So, I spent my weekend building a 100% client-side, offline-first HEIC to JPG converter: heictojpgfree.net.

The Tech Stack: How it Works Under the Hood

To make this tool lightning-fast and completely private, I designed it to run entirely in the user's browser. Here is the technical breakdown:

1. WebAssembly (Wasm) + libheif: Browsers don't natively support decoding HEIC/HEIF files yet. To bypass this, I compiled libheif (a popular C++ HEIF decoder) into WebAssembly using Emscripten. This allows the browser to parse the HEIC container and extract the raw image data at near-native speeds.
2. HTML5 Canvas: Once the Wasm module decodes the raw pixel data, it transfers the byte array to an offscreen HTML5 canvas element. From there, I use canvas.toBlob() to compress and export it as a standard JPEG file.
3. File System Access API: Users can drag and drop an entire folder of HEIC files. The tool processes them sequentially or concurrently based on the hardware threads available.

The Architectural Challenges

Building this wasn't without its hurdles. During testing, I noticed two major issues:

• Memory Leaks: WebAssembly doesn't have automatic garbage collection for C++ pointers. When batch-converting 50+ high-res iPhone photos, the browser tab would frequently crash due to out-of-memory (OOM) errors. I had to strictly manage memory allocation, ensuring every decoded frame and allocation pointer was manually freed immediately after drawing to the canvas.
• UI Thread Blocking: Initially, decoding heavy HEIC files on the main thread made the UI completely unresponsive. I resolved this by offloading the Wasm decoding process to Web Workers. This keeps the browser UI running at a buttery-smooth 60fps, even while batch-processing dozens of images.

Give it a Spin

The result is a clean, minimal utility at heictojpgfree.net. No signups, no paywalls, and absolutely no data leaves your machine.

I'd love to hear your thoughts on the performance! How do you handle heavy image processing on the frontend? Drop your feedback or questions in the comments below!