How Private Convert works in your browser

Private Convert is built around a simple constraint: the useful part of a converter is the transformation, not the upload. If the browser can do the work directly, the file can stay on your device and the result can be returned immediately in the same tab.

That means the app is mostly an orchestration layer. It accepts a file, routes it to the right browser-side utility, creates a preview, and then turns the output back into a downloadable file.

The basic flow

For most tools, the sequence looks like this:

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 creates a local preview.
5. The converted file is exposed as a download.

There is no server-side conversion queue in the middle of that flow.

How image tools work

Image tools lean on browser-native decoding plus the canvas API.

For formats the browser can decode directly, the page loads the image, draws it onto a canvas, and exports the result with the target format and quality settings. That covers the straightforward image workflows such as WebP to JPG, WebP to PNG, image compression, and browser-side resizing.

This is the lightest path in the stack because the browser already knows how to decode common image formats and canvas.toBlob() can write the final file locally.

How video tools work

Video tools use FFmpeg compiled to WebAssembly and loaded in the browser.

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

That is the path behind:

• video compression
• video to GIF
• MOV to MP4
• trimming
• cropping

The details vary by tool, but the pattern stays the same. Compression maps the quality slider to encoder settings. GIF conversion uses FFmpeg filters for frame rate, scaling, palette generation, and palette use. Trim and crop build more targeted FFmpeg commands around the uploaded clip.

The important point is that FFmpeg runs in your browser tab, not on a remote worker that receives your file.

How PDF tools work

PDF tools use a different stack because PDFs are document containers, not media streams.

pdf-lib handles structural PDF work such as:

• merging PDFs
• splitting a PDF into separate pages
• removing selected pages
• creating a PDF from uploaded images

pdf.js is used when a PDF page needs to be rendered visually, such as PDF to JPG conversion or generating a page preview. It renders the page into a canvas, and the page is then exported as a JPG in the browser.

JSZip is used when one input creates multiple outputs, such as a split PDF or a multi-page PDF to JPG export. Instead of forcing many separate downloads, the browser bundles the generated files into one ZIP archive.

How previews and downloads work

After conversion, the app creates object URLs in the browser for both previews and downloads.

That is why you can see the result immediately without waiting on a server response. The file already exists in browser memory, so the page only needs to attach it to an <img>, <video>, or download link.

The same pattern is also used for source previews where it makes sense, so the page can show the uploaded image, video, or rendered PDF page before you convert it.

Why local processing still has limits

Keeping the work inside the browser changes the trust model, but it does not remove runtime limits.

Your browser still has to decode the file, allocate memory, and run the conversion on your device CPU. That is why short videos, ordinary images, and typical PDF workflows are the best fit, while very large files or browser-specific decode gaps can still cause friction.

HEIC is a good example. If the browser cannot decode a format through its own image pipeline, a canvas-based tool cannot convert it reliably in every environment.

Why this model is useful

The browser-first approach is useful because it keeps the workflow narrow and predictable. You open a tool, run one transformation, inspect the result, and download the output without handing the original file to a remote conversion service.

That is the whole design goal: practical file utilities that feel immediate because the browser does the work itself.