How Private Convert works in your browser

Most online converters work the same way. You upload a file to someone else’s server, wait for it to process, and download the result. Your file travels across the internet twice, sits on infrastructure you don’t control, and you just have to trust that it gets deleted afterwards.

We thought that was a bad trade-off for something as simple as converting a WebP to a JPG or trimming a video clip. So we built Private Convert to do the entire job inside your browser tab — without uploads, server queues, or accounts. Your file never leaves your device.

Here’s how it actually works under the hood.

Drop a file, get a result

Every tool on the site follows the same basic sequence:

1. You drop a file into the page.
2. The browser reads that file into memory.
3. A client-side utility converts, renders, or repackages it.
4. The page shows you a local preview.
5. The converted file is ready to download.

There’s no server-side conversion happening anywhere in that flow. The browser is doing the real work, and Private Convert is the orchestration layer that routes your file to the right utility and gives you back the result.

Images: canvas does the heavy lifting

Image tools are the simplest path in the stack because modern browsers already know how to decode common image formats natively.

For conversions like WebP to JPG, WebP to PNG, image compression, and resizing, the process is straightforward: load the image, draw it onto an HTML canvas element, and export the result with canvas.toBlob() using the target format and quality settings. The browser’s built-in image decoder handles the input, and the canvas API writes the output — all without external libraries.

This is why image conversions feel almost instant — there’s very little overhead when the browser already has all the tools built in.

Videos: FFmpeg compiled to WebAssembly

Video is where things get more interesting. You can’t just draw a video onto a canvas and export it, so we use FFmpeg — the same tool that powers most professional video workflows — compiled to WebAssembly and loaded directly in your browser.

When you run a video conversion, the app downloads the FFmpeg WASM core, writes your input file into FFmpeg’s in-memory filesystem, executes the appropriate command, reads the output back, and creates a local download URL for the result.

This is the engine behind video compression, video to GIF, MOV to MP4, trimming, and cropping. The specifics vary by tool — compression maps the quality slider to encoder settings, GIF conversion uses FFmpeg filters for frame rate, scaling, and palette generation, trim and crop build targeted FFmpeg commands around the clip — but the pattern is always the same.

The important thing is that FFmpeg runs inside your browser tab, not on a remote worker that receives your file. The conversion happens on your CPU, with your memory, on your machine.

PDFs: three libraries working together

PDFs are document containers, not media streams, so they need a different approach. We use three libraries depending on the task:

pdf-lib handles structural work — merging multiple PDFs, splitting a PDF into separate pages, removing selected pages, and creating a PDF from uploaded images. It manipulates the PDF document structure directly without needing to render anything visually.

pdf.js (Mozilla’s PDF renderer) comes in when pages need to be rendered as images. For PDF to JPG conversion or page previews, it renders each page onto a canvas, which is then exported as a JPG. This is the same library Firefox uses to display PDFs.

JSZip handles the packaging when a single input creates multiple outputs. If you split a PDF or convert a multi-page document to individual JPGs, the browser bundles the files into one ZIP archive instead of forcing a dozen separate downloads.

Previews happen instantly because the file is already there

After conversion, the app creates object URLs in the browser for both previews and downloads. That’s why you see the result immediately without waiting on a server response — the file already exists in browser memory. The page just needs to point an <img>, <video>, or download link at it.

The same technique also powers source previews. When it makes sense, the page shows the uploaded image, video, or rendered PDF page before you even hit convert.

The trade-offs of running locally

Keeping everything in the browser changes the trust model — your files stay private by default — but it doesn’t remove runtime constraints.

Your browser still has to decode the file, allocate memory, and run the conversion on your device’s CPU. Short videos, ordinary images, and typical PDF workflows are the sweet spot. Very large files or long videos can push against browser memory limits.

Format support is another consideration. HEIC is a good example: if the browser can’t decode a format through its own image pipeline, a canvas-based conversion tool can’t handle it reliably in every environment. We’re upfront about these limitations rather than silently failing.

Why we built it this way

The browser-first approach keeps the experience narrow and predictable. You open a tool, run one transformation, inspect the result, and download the output — without signup forms, watermarks, or “processing your file on our servers” loading screens.

That’s the whole idea: practical file utilities that feel instant because the browser does the work itself. Your files never leave your device, and you don’t have to take our word for it — there’s genuinely nothing to upload to.