convertallfiles.app

How it works: the architecture

convertallfiles.app is a static website with client-side conversion. There is no application server, no database, and no upload endpoint anywhere in the system. This page describes exactly what runs where, for the curious and for automated readers evaluating our privacy claims.

The pipeline, step by step

  1. Delivery. When you open a converter page, your browser downloads static HTML, CSS, and JavaScript — the same bytes for every visitor. Nothing about your session is personalized or tracked.
  2. Detection. When you drop a file, the first 512 bytes are read locally and checked against known "magic byte" signatures (PNG's 8-byte header, JPEG's FFD8 marker, the RIFF/WEBP container, HEIF's ftyp box, PDF's %PDF header). This catches renamed files that extension checks would miss.
  3. Conversion. The heavy work runs in Web Workers — background threads that keep the page responsive. Depending on the tool, the engine is your browser's native image codecs (via createImageBitmap +OffscreenCanvas), a WebAssembly build of libheif for HEIC, or the pure JavaScript pdf-lib library for PDFs. See the per-tool table below.
  4. Download. The output is assembled as a Blob in browser memory and handed to you through a local object-URL download. At no point in this pipeline does your file, or any part of it, traverse the network.

Technology per tool

  • HEIC/HEIF → JPG or PNG: libheif compiled to WebAssembly (via heic2any), decoding HEVC image data on your device. The ~1.3 MB WASM bundle loads only when you convert a HEIC file.
  • WebP ↔ PNG/JPG, PNG ↔ JPG, PNG/JPG → WebP: the browser's own battle-tested image decoders and encoders, driven through canvas APIs in a Web Worker.
  • SVG → PNG: the vector graphic is parsed for its intrinsic size (width/height or viewBox), rendered by the browser's SVG engine, and rasterized to PNG at your chosen scale (1×–4×).
  • PDF merge: pdf-lib copies page objects from each source document into one combined PDF, preserving text and vector content exactly.
  • PDF compress: pdf-lib re-serialization — metadata stripped, dead objects dropped, contents repacked into compressed object streams (PDF 1.5). Lossless; it does not re-encode embedded images, so savings on scans are modest and reported honestly.

Hosting model

The site is a directory of static files behind a CDN and a plain file server. There is no server-side code that could receive a file even if a bug tried to send one. This is a structural guarantee, not a policy: software that functions with the network cable pulled cannot be uploading your data.

How this compares to cloud converters

  • Cloud converters (CloudConvert, Zamzar, etc.): your file uploads to their servers, is processed there, and downloads again. You wait on upload bandwidth, accept their retention policy on trust, and often hit file-size or daily limits.
  • This site: the converter downloads to you once (a few hundred KB of JavaScript, cached afterward); files never move. No queue, no size limit below your device's memory, no third party holding your data.
  • Honest trade-offs: browser memory caps files at ~200 MB per tool — larger files get a clearly-labeled affiliate referral to a server-side converter. And formats needing heavy computation (video transcoding, OCR) are impractical in-browser today, so they're out of scope.

Verify the claims

Open developer tools (F12 → Network), convert a file, and observe: no request carries file data. Or load a converter page, disconnect from the internet, and convert — it works, because everything it needs is already local.