File Converter: convert and compress from the Windows context menu

What the tool is for

File Converter does one thing, and it does it from the place a Windows user already looks. You select a file, or several, in Explorer, you right click, and the menu offers conversion and compression. The project description calls it a very simple tool for exactly that, and the README is at pains to say it is a personal open source project that has been running since 2014, with the author having put hundreds of hours into refining it, and with the stated goal of making conversion and compression an easy task for everyone. That framing matters for how you read the rest of the repository, because the aim was never to be a conversion engine. It is a front end that makes the conversion tools that already exist reachable from a menu, and the interesting engineering is in the Windows integration and in the middlewares, not in the conversion logic.

The middleware stack underneath

The conversion work is done by external programs, and the README credits each one with the version in use:

ffmpeg v8.0.1
ImageMagick v14.10
Ghostscript 10.02.1

ffmpeg handles the media conversion, ImageMagick handles image editing and conversion, and Ghostscript handles the PDF work, and the ImageMagick binding is the C# wrapper credited to its author. There are three more middlewares with narrower jobs. SharpShell provides the Explorer context menu extension, which is what makes the whole approach possible on Windows, and it is credited to its author. Ripper together with yeti.mmedia covers CD audio extraction, credited to another developer. And two libraries are used inside the desktop application itself rather than as external tools, Markdown.XAML for rendering markdown and WpfAnimatedGif for animated GIF display, both WPF components. The practical consequence for a user is that the capabilities of the application are the capabilities of these tools, and so are its edge cases.

The Windows shell extension, and how it is built

Adding a menu entry to Explorer is not a normal application task, and the project takes it seriously. The Explorer extension and the application need Visual Studio 2022, and the installer is a separate problem solved with the WiX toolset, which the README notes is installed through the package feed, together with the FireGiant extension for Visual Studio that makes the authoring comfortable. The last requirement is the signing tools from the Windows SDK, which is a detail worth noticing, because a shell extension that is loaded into every Explorer window is exactly the kind of component a security product and a user will be suspicious of, and code signing is how that suspicion is addressed. The solution and its project folders reflect the split, with an application directory, a middleware directory for the wrapper projects, an installer directory and a directory of preset samples.

Localisation, and the community around it

The README lists contributors for more than two dozen languages, which is a remarkable amount of volunteer work for a personal utility, and the list is a good indicator of who the tool reaches. Portuguese and Brazilian Portuguese, Spanish, Italian, German, Simplified and Traditional Chinese, Turkish, Hindi, Arabic, Greek, Hebrew, Persian, Serbian, Japanese, Czech, Korean, Vietnamese, Russian, Indonesian, Urdu, Hungarian, Polish and Swedish are all named, each with the person credited. The author also runs a donation page, points at a contributing page in the wiki, and asks for simple thanks. For an engineer evaluating the project, two things follow. The tool is used far outside its author's language, which is a good sign for the interface, and the translations are contributed rather than professional, so the quality of any given language is something to check before you trust it for a technical audience.

Where the approach stops

The limits are clear once you know the shape of the tool. It is Windows only, and it is a graphical application, so a pipeline that wants to convert a thousand files overnight has nothing to drive, since the README documents no command line entry point. Its reach is bounded by the middlewares, so a format ffmpeg cannot read is a format the application cannot offer, and the PDF path is Ghostscript, which is a set of rules about how documents are rewritten rather than a general purpose editor. The compression side has the same character, since a compressed document is a lossy operation whose quality settings live in the underlying tool. And because everything runs through the same external binaries, a version of ffmpeg that behaves differently on your machine changes what the application produces, which is why the troubleshooting page in the wiki exists and why the issue tracker is there.

The alternative, and who should choose which

The nearest alternative for a technical user is not another context menu tool, it is the command line. Running ffmpeg directly gives every option the tool has, it can be scripted, it can run in a pipeline, and it does not depend on a shell extension, a WPF application or a set of installed middlewares. The value File Converter adds is discovery and consistency, a person who does not know that ffmpeg exists can still produce a compressed video or a converted image, and a team can standardise on one place rather than on a shared wiki of command lines. So the choice follows the user. A power user with a script should learn ffmpeg. An occasional user, or an organisation that wants one tool for a help desk, should install this and use the preset samples in the repository as the starting point. A platform that has moved to the cloud, where the conversion happens in a container or a function rather than in an Explorer window, has a third answer again.

The state of the repository

The project is small, personal and still moving. The releases are v2.2 from February 2026, v2.1 from February 2025 and v2.0.2 from March 2024, so the cadence is roughly annual, and the last push to the branch was on 2026-10-19, which means work is happening between releases. The default branch is called integration, which is a common name for the branch where the current work lands before it is cut into a release, and it is a detail to keep in mind if you are pinning a version. The tree carries a changelog, the licence file, the solution, the version manifests for the two architectures of the application, the preset samples, the resources used by the interface, and the installer project. The troubleshooting documentation lives in the wiki rather than in the repository, which is the older convention but is where the known problems are.

Editorial conclusion

File Converter fits a Windows user who needs to turn a video, an image or a document into another format occasionally and does not want to learn command line tools, and it fits a team that wants one consistent place to do that with the same presets. It does not fit a pipeline, because there is no documented command line interface, and it does not fit a machine without the middleware tools it drives. Before installing it, check the presets in the repository against the formats you need, read the troubleshooting page in the wiki, and look at the changelog, since the version numbering tells you which release you are getting and the default branch is an integration branch rather than the stable one.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Tichau/FileConverter on GitHub