How hushvert keeps your files private: the architecture, and the proof

Client-side vs server-side converters: the difference that decides your privacy

Most online file converters are server-side. You pick a file, your browser uploads it to a machine you do not control, that machine converts it, and you download the result. The conversion is fine; the upload is the problem. Once your file leaves your device, its privacy depends entirely on promises you cannot verify: how long the file is kept, who can read it, whether it is logged, and what happens in a breach. In March 2025 the FBI warned that free online file-converter sites are a common vector for malware and data theft, precisely because handing a stranger's server your file is a leap of faith.

hushvert is client-side. The conversion code is shipped to your browser and runs there, on your CPU, against the file sitting in your own tab. Nothing is uploaded because nothing needs to be. This is not 'encrypted upload' or 'we delete it quickly' (both of which still require you to trust the server) - it removes the upload entirely. The distinction matters because it changes what you have to trust: instead of trusting a privacy policy, you can trust what your own network tab shows you. That is the whole moat, and the rest of this page explains how it works and how to check it.

WebAssembly: real conversion code running inside your browser

The reason hushvert can convert files without a server is WebAssembly (WASM). WebAssembly is a portable, near-native binary format that modern browsers run in a secure sandbox. It lets battle-tested conversion libraries (the same kinds of codecs and decoders that power desktop tools) compile down and execute directly in your tab, at speeds a browser could not reach a few years ago.

When you convert a JPG to PNG, decode a HEIC photo, transcode FLAC to MP3, unpack a ZIP, or rasterize a PDF page to an image, the actual work happens in WASM running on your machine. The file is read from your disk into the page, handed to the WASM module, converted, and the result is offered back to you as a download. At no point is there an HTTP request that contains your file. The only network traffic is the page itself and the one-time download of the codec (more on that below). This is why the privacy guarantee is structural rather than a setting: there is no upload step in the code path to misconfigure.

Web Workers: why a 200MB conversion does not freeze your tab

Running a heavy conversion on your own device introduces a real engineering problem: if the work happened on the browser's main thread, the page would lock up while it ran. A large audio transcode or a multi-megapixel image conversion would freeze scrolling, clicks, and the progress bar until it finished.

hushvert solves this with Web Workers. A Web Worker is a background thread the browser provides specifically so heavy computation can run off the main thread. The engine spins up a dedicated worker per conversion type (images, PDF operations, and others each get their own), constructed with the standard `new Worker(new URL(...))` pattern so the code stays auditable. The audio, video, and archive libraries manage their own worker threads internally for the same reason. The worker keeps its codecs loaded between conversions, so the second file you convert in a session is faster than the first. The practical result: the file bytes go into the worker, the conversion runs in the background, progress streams back to the UI, and your tab stays responsive the entire time. Privacy and a smooth experience are not a trade-off here; the worker delivers both.

Why HEIC conversion has to stay client-side (and why that is good for you)

HEIC is the format iPhones use for photos. It is built on HEVC, a video codec covered by a dense thicket of patents. Decoding HEIC server-side at scale would mean wading into those HEVC patent licensing issues, which is exactly why so many 'free' online converters either refuse HEIC or handle it on murky legal footing.

hushvert sidesteps the problem entirely by decoding HEIC where the patents do not create the same commercial exposure: in your browser, on your device, the same place your phone and your computer already decode it. HEIC conversion is therefore always client-side at hushvert, never on the server, on purpose. The privacy upside is a happy consequence of the legal reality: your iPhone photos, which are some of the most sensitive files people convert, are exactly the files that physically cannot be uploaded in our system. HEIC to JPG, PNG, WebP, or AVIF all run in your tab and stay there.

The proof: a CI test that fails the build if any file byte leaves

A privacy claim you cannot verify is just marketing. hushvert turns the claim into a test that runs on every single code change, so it cannot silently regress.

hushvert ships an end-to-end test gate that drives a real browser, drops a real file into the converter, runs the conversion, and watches every network request the page makes. Two layers enforce the guarantee. The gate `apps/web/tests/e2e/network-clean.spec.ts` checks that during a client conversion no third-party host is contacted (no font CDN or telemetry beacon a skeptic could point at) and that no request body exceeds about 2KB, which is room for an analytics-sized ping but far too small to hide a file: any real upload, even the first chunk of a chunked one, trips it. The shared helper `apps/web/tests/e2e/helpers.ts` names that threshold (`MAX_REQUEST_BODY_BYTES = 2048`) and is the assertion the per-pair conversion tests run, including a check that a client conversion never calls the server-job APIs (`/api/session`, `/api/jobs`, `/api/conversions`). If a future code change ever introduced a path that uploaded your file, the build would fail before it could ship. The live `/privacy-proof` page quotes that helper threshold verbatim, alongside an airplane-mode demo you can run yourself with your network disconnected.

The MIT open-source engine: auditable proof, not a black box

The conversion engine is open source under the MIT license, published on npm as `@hushvert/engine` and on GitHub at github.com/hushvert/engine. This is the strongest form of proof available for a privacy claim: you do not have to believe a description of what the code does, you can read the code that runs in your browser.

Being open source also means the no-upload property is independently checkable by anyone, not just by us. Developers can install the package and use the exact same engine in their own apps, where the file likewise never leaves the user's device (you can confirm it in your own network tab). Because conversions run on the user's CPU, there is no per-conversion server bill, which is part of why the engine can be free and unlimited rather than rate-limited. For people who simply want assurance, the takeaway is the same: the moat is not a trade secret. It is a public, MIT-licensed codebase plus a CI test, both of which you or any third party can inspect.

The honest server lane: what genuinely cannot run in a browser, and what happens to those files

We will not claim everything is client-side, because it is not, and overclaiming would undermine the whole point. A small set of conversions depend on software a browser cannot run: office document layout engines (DOCX, DOC, XLS, XLSX, PPT, PPTX, ODT, ODS, ODP, RTF, and HTML to PDF), PDF to Word (pdf-to-docx), and video large enough to exceed what a browser can encode. Those genuinely require a server.

For those, hushvert is explicit. The dropzone labels the conversion 'this one leaves your device' before you start, so you are never surprised. The file uploads over an encrypted connection, is converted, and is deleted: the input immediately after conversion, the output within about an hour. HEIC is never on this list (it stays client-side for the patent reasons above). And everything the browser can do (all image, HEIC, audio, archive, and supported PDF page conversions) stays on the free, unlimited, no-account, no-upload lane. The server lane is the documented exception, not the default. Knowing exactly where the line sits is part of how you can trust the rest.

Keep reading

• See the live no-upload proof
• The open-source engine (MIT) and developer API
• Are online file converters safe?
• Private file converter

Common questions

Is hushvert private?

Yes, for every conversion a browser can run. Images, HEIC photos, audio, archives, and supported PDF page operations are converted in WebAssembly inside your browser, so the file's bytes never leave your device. You can verify this yourself by watching your browser's Network tab, or by running the airplane-mode demo on the /privacy-proof page with your network disconnected. A CI test also enforces the no-upload guarantee on every code change, and the engine is open source under the MIT license. The one exception is a clearly labeled server lane for office documents, PDF-to-Word, and oversized video, where files are deleted right after conversion.

How does client-side file conversion work?

Your browser downloads the conversion code (compiled to WebAssembly) once, then runs it locally against the file in your tab using your own CPU. The work happens in a Web Worker, a background thread that keeps the page responsive even for large files. Because the conversion runs on your device, there is no upload step: the file is read, converted, and offered back to you as a download without any network request carrying its bytes. The first conversion in a session downloads the codec, which is then cached so later conversions start instantly.

What is the difference between a client-side and a server-side converter?

A server-side converter uploads your file to a remote machine, converts it there, and sends back the result, which means the file's privacy depends on a server you cannot inspect. A client-side converter ships the conversion code to your browser and runs it on your device, so the file never leaves at all. The practical difference is what you have to trust: with server-side you trust a privacy policy, with client-side you can verify the absence of an upload in your own network tab. hushvert is client-side for everything a browser can handle and uses a server only for a small, clearly labeled set of formats that genuinely cannot run in a browser.

Can I verify that my file is not being uploaded?

Yes, in three ways, strongest first. You can convert a file with your network disconnected (airplane mode) using the demo on the /privacy-proof page, which only works because no upload is involved. You can open your browser's developer tools, switch to the Network tab, and convert a file: you will see the page assets and a one-time codec download and nothing carrying your file. And you can read the CI test that fails the build if any request body exceeds 2KB during a client conversion, plus the MIT-licensed engine source itself.

Why does hushvert use a server for some conversions?

A few conversions depend on software a browser simply cannot run: office document layout engines (like DOCX, XLSX, and PPTX to PDF), PDF to Word, and video large enough to exceed the browser's encoding ceiling. Those need a server. hushvert labels these in the dropzone before you start, uploads over an encrypted connection, and deletes the files afterward (inputs immediately, outputs within about an hour). HEIC is never sent to the server; it stays client-side on purpose because of HEVC patent reasons. Everything else a browser can handle stays on your device.

Why does HEIC conversion stay in the browser?

HEIC is based on HEVC, a video codec covered by extensive patents that make server-side decoding at scale legally fraught. hushvert decodes HEIC in your browser instead, the same place your phone already decodes it, which avoids the patent exposure and, as a bonus, means your iPhone photos are physically among the files that cannot be uploaded in our system. HEIC to JPG, PNG, WebP, and AVIF all run in your tab and the bytes stay there.