Filee and the case for a converter that never opens a window

A converter with no app window to open

Filee is a free, open source file converter written in C#, and its central design decision is stated in the README as a free converter you use by dragging. You hold a key, Ctrl on Windows or Option on macOS, drag files, and a donut of formats opens at your cursor. You drop a file on the format you want and the result appears next to the original. There is no application window to bring forward, no import step, no output folder dialog.

The problem this solves is a small, real friction. A person who converts a handful of files a week currently opens a web converter, uploads documents that may be confidential, waits, and downloads. Or they open a command line tool and read a help page. Filee removes both steps by making the OS file manager the interface, and it does so without a server, because the README states that nothing is uploaded and that the program works offline.

The target user is someone who converts documents rather than builds software: someone handling Korean HWP and HWPX files, Word and Excel exports, images in odd formats, or video and audio that needs transcoding, on a machine with no Office, Hancom Office or LibreOffice installed. The README states that images, PDF, Word, Excel, PowerPoint, HWP, e-books, archives, fonts, CAD and 3D models work without those programs.

Under the hood it is a .NET desktop application. The repository holds a solution file, central package and build property files, a global.json pinning the SDK, and separate src/, tests/, build/ and installer/ trees. The topic tags attached to the project name Avalonia, the cross-platform UI framework, which is consistent with a single codebase shipping Windows, macOS and Linux builds.

The donut filters itself to the files you dragged

The mechanism behind the headline feature is a format filter that runs on what you are dragging. The README says that only the ones that make sense for the files you drag appear, so the ring is not a fixed list of 247 entries. Drop a photo and you get image targets; drop a spreadsheet and you get tabular targets.

The ring is also user arranged rather than fixed. The features list describes one toolbar per file type, arranged by drag and drop, with presets for quality, size, DPI, PDF pages and compression, video and audio, output folder and file names. The screenshots section shows a toolbar editor with profiles and presets, so the per-file-type configuration lives in a profile that you shape once and then reuse.

Batch behaviour is handled explicitly. Many files can be converted at once, in parallel, and the README states that routes with several steps are found automatically, giving HWP to HWPX to DOCX as the example. That automatic route finding is the part that matters in practice, because a user who wants a DOCX from an HWP file does not want to know that the conversion is a two step path.

The donut is a drag-and-drop gesture, and gestures are the weak point of this design on Linux. The install notes state that drag gestures need X11, and that on Wayland you should use the drop zone and the file manager right-click menu instead. The same interaction that makes the product pleasant on Windows and macOS is the one that degrades first elsewhere.

Watch folders, the filee command and the other ways in

The drag gesture is the headline, but the README lists several other doors into the same engine: the right-click menu, a keyboard shortcut, the drop zone, and the filee command. The home screen shown in the screenshots is a drop zone plus a list of recent conversions, which covers the case where dragging is inconvenient.

Watch folders are the feature that turns a desktop toy into a repeatable process. The README states that watch folders convert every file that lands in them, so a conversion pipeline can be a folder that a scanner or a colleague writes into, with no one at the keyboard. That is the closest the project comes to automation, and it is the mechanism most worth understanding before adopting it.

The filee command exists as a command line entry point, and on Windows the installer can register it. The README links to a command line section where those subcommands and flags are documented. If you plan to script Filee, that section is the first thing to check: a converter marketed on drag and drop tends to expose a small CLI surface, and the CLI is one of several routes into the same engine.

A related detail: on Windows the setup can add the Explorer menu entry, start at sign-in, the filee command and optional engines. Those optional engines are the mechanism behind the footnote markers in the format table, and they matter when you plan a deployment.

Installing on Windows, macOS and Linux

There is no package manager route in the README. Installation starts from the Releases page, and the platform instructions differ sharply in how finished they feel.

On Windows 10 and 11 you run the setup executable, or unzip the portable archive and run the executable from it:

Filee-<version>-win-Setup.exe

Filee.exe

On macOS 14 and later, which the README labels as preview, you unpack the arm64 or x64 package and run the installer script:

./install.sh

The README is explicit about the catch on that platform. The build is not notarized yet, so the first start has to be allowed manually in System Settings, under Privacy and Security, with Open Anyway. That is an ordinary macOS workflow, and it is still a step that will look like a warning to anyone less technical.

Linux x64 and ARM64 is also labelled preview, and the README puts the requirement at Ubuntu 22.04 or later. You unpack the package and run the same installer script, with no root needed, and Python 3 has to be present:

./install.sh

The README also states that the application shows new releases in its menu and updates itself, keeping your settings and engines. For a managed environment that is a decision point rather than a convenience, because a self-updating desktop binary is harder to pin and audit than a versioned package.

247 formats, and what the footnote markers hide

The format coverage is broad by any standard, and the README table is organised by family rather than by a flat list. Images cover JPG, PNG, WEBP, AVIF, TIFF, BMP, GIF, APNG, ICO, ICNS, JPEG XL, JPEG 2000, PSD and PSB, TGA, HEIC, QOI, DDS, PCX, CUR, and reading of GIMP XCF, camera RAW files such as CR2, CR3, NEF, ARW and DNG, DICOM, OpenEXR, HDR and JPEG XR on Windows.

Vector handling is where the interesting conversions live: SVG, SVGZ, EMF, WMF, AI, EPS, PS, CDR, VSD, CGM, ODG and FODG in, and PDF with vector output, SVG to DXF or DWG, and PDF to EPS or PS among the targets. PDF itself can be split, merged, page-ranged and compressed. Documents cover DOCX, DOCM, DOTX, EML, Outlook MSG, DOC, ODT, FODT, RTF, WPS, WPD, Pages, ClarisWorks and MacWrite, with outputs to PDF, DOCX, HWPX, EPUB, TXT and HTML.

The structure of that table is the interesting part. Each family has a list of inputs, a list of outputs, and superscript markers attached to specific entries. The marker 1 attaches to PS as a vector input, marker 2 to FODG and to a long tail of legacy document formats such as ODT, FODT, OTT, ClarisWorks, MacWrite and T602, marker 3 to the text conversions that include PPTX slides, marker 4 to e-book targets, and marker 5 to HEIC, video and audio. Those markers point at functionality that depends on the optional engines the Windows installer offers. The description says 244+ formats while the README table says 247, and the footnote system means the true count depends on which engines you have installed.

The HWP and HWPX support is the differentiator worth calling out for anyone outside the Korean market, because no mainstream office suite on a Western machine reads those files, and Filee converts HWP and HWPX to and from PDF, PNG, DOCX, TXT, Markdown and HTML.

Preview status on two of three platforms

The honest summary of platform maturity is visible in the badges: Windows 10 and 11 are the supported target, while macOS and Linux are marked preview. The README repeats this in the install section, calling the macOS package a preview and the Linux package a preview for Ubuntu 22.04 and later. Two of the three platforms are therefore explicitly provisional, and the macOS build carries an additional wrinkle in that it is not notarized.

Linux is the thinnest case. Drag gestures need X11, so on a Wayland session the primary interaction of the product is unavailable and you fall back to the drop zone or the file manager right-click menu. The install also requires Python 3 to be present, which is unusual for a C# application and implies a helper script in the packaging.

There is no batch or scriptable mode documented beyond the watch folder and the filee command. For a service that converts hundreds of documents a day on a server, the absence of a documented headless interface, along with the self-updating behavior and the missing notarization on macOS, is the reason to look twice before adopting Filee as infrastructure rather than as an application. As an application for a person at a desktop, the same constraints are much easier to accept.

MIT licensing, recent releases and the dependency surface

Filee is released under the MIT license, and the README carries an MIT badge pointing at the LICENSE file. The repository also ships THIRD-PARTY-NOTICES.md alongside the license, which is where the attribution for the embedded libraries and any bundled components would be recorded. A permissive license is the simplest part of the adoption question here, subject to reading THIRD-PARTY-NOTICES.md for the components that ship inside the build.

The release history is dense and recent. v1.10.4 was published on 2026-10-15, v1.11.0 on 2026-10-17, and v1.12.0 on 2026-10-19, and the last push was on 2026-10-19. The repository is not archived, and CHANGELOG.md at the root is where the detail between those versions lives.

That pace is good news for bug fixes and a constraint for deployment. The application also updates itself from its own menu, keeping settings and engines, so a machine that installs it once will not stay on the version you tested. The repository structure supports the usual workflow, with tests/ and build/ directories and a .github/ directory for workflows, and the README links to a CI badge for the ci.yml workflow. A team that wants reproducible conversions should pin a release manually, watch CHANGELOG.md, and decide explicitly whether the self-updater stays enabled.

Editorial conclusion

Filee suits a person or a small team that converts office documents, HWP files, images and media on a desktop and refuses to upload client material to a web converter. It does not suit a server-side pipeline that needs a scriptable interface with documented flags, and on Linux the drag gesture needs X11. Before adopting it, run the filee command on one of your real HWP or MSG files and read CHANGELOG.md for the version you installed, since v1.10.4, v1.11.0 and v1.12.0 were published within four days of each other.

Frequently asked questions

Official sources

1. KnifeLemon/Filee on GitHub
2. License: MIT
3. Project website
4. README
5. Releases