How Kit-Bin Actually Works
Every file-conversion site says some version of "we respect your privacy." Most of them still upload your file to a server to actually do the conversion. The privacy claim is a policy decision about what they do with your file afterward, not a technical guarantee about whether your file reaches their server in the first place.
Kit-Bin is different in a way that's worth explaining properly, because "trust us" isn't a technical argument. Here's what's actually happening.
The short version
When you drop a file into a tool on this site, it never gets sent anywhere. The conversion happens inside your own browser, using your own device's processing power, and the result is handed back to you directly. There is no upload step for any of the tools currently on this site, not a fast one, not an encrypted one. There isn't a network request carrying your file at all.
The slightly longer, actually technical version
Browsers have supported a technology called WebAssembly (often shortened to WASM) since around 2017. WebAssembly lets code written in languages like C++ or Rust, the kind of code that historically only ran as a native application installed on your computer, run directly inside a web page, at speeds close to a native app, without a plugin.
That matters here specifically because real file-format libraries (PDF manipulation, image codecs, audio/video processing) are complex pieces of software. Before WebAssembly, running that kind of processing in a browser wasn't practical, so every "online converter" had to send your file to a server, run the real processing software there, and send the result back. That's still how most competing tools work today.
Kit-Bin compiles those same kinds of processing libraries to WebAssembly and runs them directly in your browser tab. Your file is read into your browser's own memory (the same way any file you open in any app gets read into memory), the WebAssembly module processes it right there, and the output gets handed to your browser's normal file-download mechanism. At no point does the file's data get packaged into a network request.
Why this is a stronger claim than "we promise not to look"
A server-based converter could, in principle, be perfectly trustworthy. Plenty are. But you're relying on a policy: a company's stated intention not to retain, inspect, or misuse your file once it's on their server. That policy could be wrong, could change, or could simply not survive contact with a data breach.
Kit-Bin's model removes the question entirely rather than answering it well. There's no server in the file's path to have a policy about. This is a structural fact about how the site is built, not a promise about how it's operated. See the Privacy Policy for the exact, current wording of what that means for each tool.
The honest limits of this approach
This isn't a claim that browser-side processing can do everything. Some operations, very large video files, or converting between complex office-document formats, currently don't have a practical browser-only solution and either aren't offered on this site yet, or would need a server component if they're added later. If that ever applies to a specific tool, that tool's own page will say so plainly, and the Privacy Policy will be updated to reflect it before it ships. Nothing on this site claims "100% private" in a blanket way that isn't true for every tool that carries the claim.
Related tools
Every tool currently on this site works exactly as described above. Browse the full list on the homepage, or start with one of the most-used ones: Merge PDF, Compress Image, Trim Audio.
Further reading
- WebAssembly — MDN Web Docs
- File API — MDN Web Docs
- Inspect network activity in DevTools — Chrome for Developers