Local File Processing

Last updated: October 2026. Almost every file site claims to be "private." Most mean "we promise to delete your upload." This guide explains the difference between a promise and an architecture: why tools that process your files inside the browser remove the risk entirely, when that matters, and how to check any tool's claim yourself in under a minute.

The difference in one sentence

An online converter copies your file off your device, sends it across the internet to a server, processes it there, and sends a result back. A local tool runs the actual conversion code on your own machine, so the file is never copied anywhere at all. The first design has to be trusted; the second does not need trust because the risky step simply never happens.

What "upload to convert" actually exposes

Sending a file to a server puts it in play at every point of its journey:

In transit — even over HTTPS, the operator's servers terminate the connection and hold the plaintext file.
At rest — your upload sits on disk somewhere, in a bucket or temp folder you cannot see or audit.
Retention — "deleted after 1 hour" is a policy the operator can change, quietly fail, or be compelled to break; backups and logs often outlive it.
Human and third-party access — support staff, debugging dumps, analytics, or an acquired company can all end up able to read stored files.
Model training and reuse — some free services have been shown to harvest uploaded content; the terms of service decide, and almost nobody reads them.
Breaches — a server holding thousands of strangers' documents is a target. When it is breached, your file is in the leak.

None of this implies malice. It is the ordinary surface area of any service that receives data. The point is that every one of those risks requires the file to leave your device in the first place.

Why local processing removes the problem structurally

A tool that converts a file in your browser tab has nowhere to leak it, because it never gets the file. The code — often compiled to WebAssembly so it can run fast in the browser — executes on your CPU using your memory, and the result goes straight to your download folder. What never crosses the network is your file; the only requests the tool makes are for code and assets, never carrying your document's contents. This is why local-first tools can honestly say there is no queue, no daily cap and no account: there is no server doing the work, so there is nothing to meter or log.

Why a promise is weaker than an architecture

Trust-based privacy asks you to believe a chain of things you cannot verify: the current policy, that the code enforces it, that no bug or human overrides it, that a future owner honours it. Architecture-based privacy collapses that chain to a single checkable fact — did a copy of my file get sent anywhere? For a browser tool, you can answer that yourself (see the section below). A promise can also be legal cover: it commits the operator, but operators change, get hacked, and get acquired. An upload that never happened cannot be breached, subpoenaed, or quietly retained.

When local processing is the right call

Prefer an upload-free tool whenever the file has any personal or professional stakes:

Government ID scans, passports, contracts or tax forms — turning those into a PDF locally (JPG to PDF) avoids shipping sensitive documents to a stranger's server.
Medical reports, legal exhibits, unreleased work, or anything under an NDA.
Private photos — especially from an iPhone, where you may want HEIC to JPG without the originals being stored in a datacenter.
Bulk jobs, where you would otherwise be uploading hundreds of files and trusting each one.

The honest trade-offs

Local is not free of costs, and pretending otherwise would be its own kind of dishonesty:

Your hardware does the work — a very large or high-resolution file can be slow on an old phone and may hit browser memory limits where a big server would not.
No server-side recovery — nothing is saved, so close the tab and the result is gone; download it. That is the privacy working as intended, but it means you keep the copies.
The code still comes from someone — you are trusting that the script you downloaded does what it says. That is why open, verifiable behaviour matters more than a logo.

Prove it yourself, in under a minute

Do not take our word for it — test any "private" file tool, ours included:

Watch the network. Open the browser's DevTools (F12) to the Network tab, drop in a file, and confirm no request carries it. A genuine local tool uploads your file nowhere — you may still see requests for the page's own code and, on ad-supported sites, third-party scripts, but none of them contain your document.
Go offline. Run a tool once while online — that fetches its code (and, for WASM tools, the codec) into the browser's cache. Disconnect and run it again: it still converts, which proves no server is doing the work. The one thing that does need the network is a first-ever cold visit to a page you have never loaded — after that, the code is cached and the processing is offline.
Read the promise precisely. "Private" can mean "we encrypt the upload" — still an upload. Only "runs entirely in your browser / no upload" describes the architecture above.

How this site does it

Every tool across these 38 converters runs the real encoder, decoder or PDF engine as WebAssembly or via the browser's own canvas, so your files are never transmitted, stored or logged by us. The About page explains the principle — a privacy tool should not require you to trust it — and the contact page is the only place you ever send us anything, deliberately, for support. To see the approach on real files, try Compress PNG, Resize Image or HEIC to JPG; for the format side of things, read our JPEG XL guide or the AVIF vs WebP vs JPEG XL comparison. Wrong anywhere? Tell us and we will fix it.