Methodology · The whole pipeline

How nothing leaves your browser.

"We don't upload your files" is a claim every converter site makes, including the ones that upload your files. This page doesn't ask you to believe the claim — it shows you the pipeline and gives you three independent ways to catch us if it were false.

Files uploaded0 Server-side codenone Data stored about younone Works offlineyes

These aren't marketing numbers — each one is checkable from your side of the screen, and the sections below show how.

The pipeline, start to finish

When you choose a file on any converter here, your browser's File API opens it in memory — the file is already on your machine, so nothing travels anywhere. Decoding turns the bytes into raw pixels: for JPG, PNG, and WEBP the browser's own decoder does this natively; for HEIC, which most browsers can't read, a WebAssembly build of the open-source libheif library does it inside the tab. The pixels are drawn onto a canvas, re-encoded into the output format, wrapped in a Blob — a chunk of memory in your tab — and linked for download. The audio converters follow the same shape: your browser's own audio engine decodes M4A, WAV, or the audio track inside a video into raw samples, and an open-source MP3 encoder running in the tab re-encodes them. The GIF maker does the same with pictures instead of sound — the browser's own video player steps through your clip, a canvas samples the frames, and an open-source GIF encoder in the tab assembles them. The morse decoder is the reading instrument of the family: the browser decodes your recording into raw samples the same way, and this site's own JavaScript measures the keying and prints text — nothing downloads for that page, ever. The BPM counter is the second of those reading instruments and works to the same shape: the browser decodes and resamples your song, this site's own filterbank and autocorrelation measure the spacing between its beats, and what comes back is a tempo in beats per minute with the readings it could not rule out named beside it — again with nothing downloaded at any point. Six steps, all local. A server never appears in that sequence because this site does not have one: it is static files served from a CDN, with no backend, no database, and no API to receive an upload even if the code tried to send one.

Verify it — three independent ways

The network meter. Every converter's readout strip has a "network since file read" instrument. It uses your browser's own PerformanceObserver to count the network resource requests your browser records from the moment your first file is read — it reads 0, in green, and flips red on the first one. Being honest about its limits makes it more useful, not less: it deliberately excludes the one-time decoder download (that happens before your file is read), and resource timing doesn't surface WebSocket traffic — which is why the airplane-mode check below, not this meter, is the definitive proof. There are no WebSockets here; the meter is the convenient check, the offline test is the airtight one.

The developer-tools check. Press F12, open the Network tab, then convert a file. After the one-time decoder fetch (which happens before your file is read — see below), the request list stays empty. This check doesn't rely on anything we wrote; it's the browser reporting on us.

The airplane-mode check. The strongest one, because it cannot be faked. Visit the converter you need once — for HEIC, give the one-time decoder a moment to download — then switch off wifi entirely and convert. It works, because nothing about the conversion ever needed a connection. A site that secretly uploaded your files could not pass this test, no matter what its copy says. That structural difference is the entire reason this site exists.

The three things that do download: a decoder and two encoders

Honesty requires naming the exceptions — there are exactly three, and all of them download before any file of yours is read, so the network meter's zero is honest. HEIC decoding needs code your browser doesn't ship: a 1.4 MB WebAssembly build of libheif v1.19.8 (with the libde265 HEVC decoder), the same open-source library used industry-wide, served unmodified from this site under the LGPL-3.0 license with the license text and provenance published alongside it. The source for this exact build is the libheif-js 1.19.8 package, pinned by SHA-256 in the provenance file — the version you download here, not a moving branch. It downloads once per device — never in response to your file — and after the first visit it lives in your cache, which is why the tools work offline. There is no analytics beacon here either, deliberately: a page that promises zero requests should not make one to count you.

The audio converters carry the mirror-image exception. Decoding your files — M4A, WAV, the audio track inside a video — is done natively by your browser, so nothing downloads to read them; but browsers cannot write MP3, so that half is done by open-source code served from this site. MP3 encoding by lamejs (LGPL), a JavaScript port of LAME — lame.sourceforge.net. It is served unmodified, unminified, and human-readable — the ~518 KB file you download is its own source code — with the upstream license, the full LGPL-2.1, LGPL-3.0 and GPL-3.0 texts, and its pinned provenance all published beside it. Like the decoder, the encoder is fetched once, before your first file is read, and then lives in your cache.

The GIF maker carries the third and last exception, with the same shape. Your browser decodes the video itself — its own <video> element steps through the frames, so this site serves you no video decoder — but browsers cannot write animated GIF, so that half is GIF encoding by gif.js (MIT), which runs in a background worker and uses Anthony Dekker's NeuQuant color quantizer, whose original 1994 copyright notice is kept intact in the served file — that notice's survival is its license's one condition. The license text and pinned provenance are published beside it. These three libraries — one decoder, two encoders — are the only third-party code on the site; everything else here is original, and every one of the three is fetched before your first file is read. The 3D pair is where that gets its strongest form: both 3D routes parse the formats first-party and draw with the browser's own WebGL — they load no vendored byte and fetch nothing at any point, so the network meter's zero on those two pages has no exception to disclose.

What never exists here

No accounts and no sign-ups. No cookies. No local storage — not even a settings byte; close the tab and every trace of your session is gone, because results live in tab memory and are released when you leave. No copies "deleted after 24 hours," because no copies exist to delete. And one side effect worth knowing: re-encoding through a canvas strips EXIF metadata from every output — GPS coordinates, device model, timestamps. For photos you're about to share, that's a privacy feature; if you need the capture date, note it before you convert.

The honest limits

Client-side conversion spends your device's resources instead of a server's. Decoding happens in RAM at about four bytes per pixel, and the decoder holds a full frame of its own alongside the canvas copy, so a 48-megapixel HEIC peaks at roughly 400–600 MB while converting — the lever is the resolution of a single image, not how many you queue. HDR and 10-bit captures are tone-mapped to standard 8-bit color, since that is what JPG and PNG hold. Very old browsers without WebAssembly can't run the HEIC decoder at all — the page will say so rather than quietly failing. These are the trade-offs of the architecture; we consider them a fair price for the property that no file of yours ever exists anywhere but in your hands.

Try it