The converter comes to your file

Why this design

Running conversions in the browser is more work to build than shelling out to a server. It is worth it for three reasons.

Privacy stops being a promise. There is no upload, so there is no retention policy to trust, no breach to worry about, and nothing to delete afterwards. You can verify it by disconnecting from the internet mid-session.

It is often faster. A 40 MB video does not need to travel to a server and back. For anything up to a few hundred megabytes, a modern laptop beats the round trip.

It scales without cost. A thousand people converting simultaneously costs nothing extra, because each conversion runs on their own machine. That is what makes the free tier sustainable rather than a loss leader.

Where the approach runs out

Browsers have real limits, and FileTools360 names them rather than papering over them. WebAssembly is 32-bit, so memory tops out around 2 GB — multi-gigabyte video will not work. Legacy binary formats such as .doc and .ppt are undocumented and need LibreOffice to read reliably, which cannot run in a tab. DRM-protected e-books cannot be converted at all, and FileTools360 will not attempt it.

Those conversions are listed in the directory as unsupported, each with the specific reason and a suggested alternative, so you find out before choosing a file rather than after.

Loading only what you need

Every processor is loaded on demand. Opening the homepage downloads none of the conversion engines. Converting a CSV loads the spreadsheet parser and nothing else. Only when you convert a video is the FFmpeg core fetched — and it is then kept warm for 90 seconds in case you convert another, after which its memory is released.

How the measured figures are produced

311 converters and 48 tools carry a table of measured results rather than an estimate. Those numbers are not quoted from a vendor, carried over from a blog post, or rounded by hand. They come out of a script in this project's repository, and you can regenerate every one of them with a single command:

npm run seo:benchmark

The corpus is synthetic and seeded. Each sample isolates one property that formats treat differently — a smooth gradient, hard-edged text, film-like noise, flat colour, a transparent edge, a nested record, a field full of commas — so the results explain why two formats diverge rather than only reporting that they did. Nothing depends on a photograph we happen to own, which is what keeps the figures reproducible by someone who is not us, and free of any licensing question.

The trade is that synthetic samples predict the shape of your result rather than its exact size. A table saying PNG came out twenty times larger than the JPEG that went in is telling you something true about those two formats; it is not promising you a number for your own photograph.

Where it can, the harness runs this site's own converter — the same code, the same libraries, the same default settings as the browser — so the bytes measured are the bytes you would download. That covers the data, spreadsheet, TIFF and GIF conversions. It cannot cover JPEG, PNG, WebP and AVIF, because those are encoded by your browser's own encoder, which has no equivalent outside a browser; those are measured with the same codecs at the same quality from a different implementation, and every page that does so says which of the two it is instead of averaging the distinction away.

The audio and video conversions are measured differently again, and more strictly. Their engine is FFmpeg compiled to WebAssembly, which only runs in a browser, so rather than substituting a native FFmpeg — a different build with different defaults, confidently wrong — a script drives a real browser, runs each conversion through the engine you would use, and records what came out. Those figures are the product's own output.

Each of those is measured twice, on an easy clip and a hard one, and the reason is worth stating because it was a mistake first. With a single clean tone, converting FLAC to MP3 measured the file getting larger — true of that clip, since FLAC compresses a pure tone almost perfectly while MP3 will not go below its bitrate floor, and the exact opposite of what happens to real music. One sample measures the sample, not the codec.

Where a tool cannot be measured honestly, it is not measured. The PDF compressor is the clearest case: most of its work is re-encoding the images inside a document, which needs a browser, and without one it reports a scanned file as unchanged. That figure is available, repeatable and completely misleading, so it is not published. The same rule keeps the video and audio tools out — they need FFmpeg, which only runs here as WebAssembly in your browser — which is why their tools are unmeasured even though their conversions are not: trimming or merging needs a choice about where to cut, and a benchmark that picks one is describing its own choice.

Built from one registry

All 527 converters, plus their pages, metadata, structured data, search index and internal links, are generated from a single conversion registry spanning 11 categories. Adding a converter means adding an entry, not building a page.

Browse the full directory →