We built a converter that runs on your machine.

Search for “convert HEIC to JPG” and the first ten results all look the same. A landing page with a giant upload button, three interstitial ads, a cookie banner that demands eight clicks to refuse, and small print explaining that your photos will live on someone else’s server for the next twenty-four hours — or longer. You hand over a wedding photo, a passport scan, an internal slide deck, and you have no way to verify what happens to it after the download link goes green.

That model exists because it pays. Bandwidth is cheap, advertising networks are cheaper, and the average user does not read terms of service. The result is a category of utility software where the business model is fundamentally at odds with the user’s interest.

LocalConvert is built on the opposite premise. The conversion happens on the device that already owns the file. The browser fetches the HTML, the JavaScript, and the WebAssembly binaries it needs to do the work, and after that point your file does not leave the page. There is no “temporary storage” clause, no retention policy to trust, no server log to subpoena. The math is simpler: if the bytes never travel, they cannot be intercepted, archived, or sold.

This isn’t a new idea. Photoshop, HandBrake, and a hundred other desktop tools have done conversion locally for decades. What changed is that the browser became powerful enough to host the same native code — via WebAssembly — without requiring an install, without asking for admin rights, and without locking you into a single operating system. The work that used to demand a desktop client now fits inside a tab, and we think that’s the right place for it.

Privacy is a side effect of the architecture, not a promise bolted on afterwards. We could not exfiltrate your file if we tried, because the JavaScript that runs in your browser does not have a network channel pointing at our infrastructure for that purpose. The engineering choice and the ethical claim are the same choice, made once. That alignment is what made this project worth building.

Nothing on this site is novel cryptography or a new codec. The interesting work lives upstream, in projects that have been refined by thousands of contributors over decades. LocalConvert is a careful assembly of those projects, ported to the browser, and presented in an interface that respects your time.

Direct credit, with links:

• FFmpeg — the audio and video pipeline, including every codec, demuxer, and filter we expose.
• ImageMagick — raster image decoding, encoding, and colour management.
• Pandoc — document conversion across markup languages and office formats.
• Emscripten — the toolchain that makes any of this possible by compiling C and C++ to WebAssembly.

LocalConvert is a continuation and a fork of VERT-sh, an earlier in-browser converter project. We took the foundation, rebuilt the UI for editorial clarity, expanded the format catalogue, and stayed close to the original ethos: tools that work for you, not on you.

Our license remains AGPL. If you fork this repository, the obligation to publish your modifications travels with it. The point of that choice is to keep the “upload nothing” promise verifiable: anyone running a hosted version of this codebase must expose their source, which lets the community confirm the network behaviour matches the claim. Closed-source forks would defeat the mechanism that makes the trust model checkable in the first place.

Beyond the named tools above, this project also draws on the broader WebAssembly ecosystem: the small army of maintainers who keep Emscripten ports of native C and C++ projects working as both the upstream and the browser move forward. Their work is mostly invisible to end users, and mostly thankless. If any of this is useful to you, consider sponsoring one of those upstream projects directly. They need the support more than we do.

LocalConvert is currently maintained by a small team that handles hosting, format coverage, and the slow grind of keeping WebAssembly builds aligned with upstream releases. We have not invented a corporate persona for this page; the honest answer is that the project is small, technical, and run by people who care about file formats more than is reasonable.

If you want to contribute — whether that means fixing a bug, improving the Polish translation, adding a format, or arguing about colour profiles — the code is on GitHub and the issue tracker is open. Pull requests are read. Bug reports with sample files and a browser version are read first.

We are deliberately careful about scope. New features arrive slowly because every additional codec, format, or option is more code to maintain, more bytes to ship, and another surface for bugs to hide in. The fastest converter is the one that does what you need and nothing more. If you propose a feature and we decline, it’s rarely because the idea is bad — usually it’s because we can’t commit to maintaining it for the long haul.

Funding is straightforward: we don’t take money for this. No ads, no premium tier, no “pro” conversions behind a paywall. The site is cheap to operate — static hosting plus a small analytics box — and we’d rather keep it that way than introduce the incentives that come with a revenue model.

github.com/VERT-sh/VERT

For private questions, security reports, or partnership inquiries: [email protected]. We read every message, though our reply time depends on how busy the queue is.

For bugs, feature requests, or anything that benefits from being public: open an issue on GitHub. That is also the right channel for proposing a new format.

For real-time chat and informal conversation, the Discord server is small and friendly. Drop in, lurk for a while, ask a question.

A note on security disclosure: if you find a vulnerability that could compromise file privacy — a way to exfiltrate a buffer, a CSP bypass, anything that would let a third party see a user’s content — please report it via email rather than the public issue tracker so we have time to fix it before the details spread. We do not run a formal bug bounty, but credit is given freely and we prioritise these reports above everything else.

Beyond that, if you simply want to tell us a file format you couldn’t convert, a translation that reads awkwardly in your language, or a workflow that would feel more natural with a small UI change — we read everything, and even when we can’t act on a request, the data point is useful. Most of the improvements shipped over the last year came from offhand comments in the Discord rather than formal feature requests.