MDFlux: A Local-First Document-to-Markdown Converter Built Around MarkItDown
Turn any document into clean, AI-ready Markdown. Local-first desktop app: reads scanned PDFs, batches folders, runs offline, and uses far fewer tokens than vision models.
At a glance
- What is it?
- MDFlux is a Tauri desktop app that wraps Microsoft's MarkItDown engine with OCR, batch folder processing and an optional cleanup pass. It is aimed at people feeding documents into LLMs who do not want to send pages to a vision model, and the README makes a specific token-cost argument for that choice.
- Who is it for?
- Adopt MDFlux if you are on Windows or Linux x64, your documents are mostly born-digital or lightly scanned, and you want an offline conversion step before a retrieval or summarisation pipeline. Do not adopt it if you need macOS, a headless server-side converter, or a documented CLI and API surface, none of which the supplied material confirms.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem MDFlux targets: getting documents into an LLM without shipping pixels
The README frames the problem in cost terms rather than convenience terms. Two common paths exist for getting a document into a model. The first dumps raw extracted text, which loses headings, tables and list structure. The second sends page images to a vision model, which keeps the layout but means the documents leave the machine and the cost is charged per page. MDFlux positions itself between those: local conversion to structured Markdown, with OCR for pages where plain extraction returns nothing. The stated audience is anyone assembling RAG inputs, summarisation pipelines or batch document workflows where the same file gets read repeatedly. The token argument is the load-bearing one. The README claims a page sent as an image typically costs well over a thousand tokens regardless of how little text it holds, while the same page as Markdown is usually a few hundred. That claim is the project's own, not an independent measurement, and the numbers in the comparison table (0 usable tokens for a plain extractor, 10,731 for a vision model, 1,893 for MDFlux OCR) come from the README's own example rather than a reproducible harness you can inspect in the supplied material.
How the conversion pipeline is put together
MDFlux is not a from-scratch parser. The README states it is built on Microsoft's MarkItDown, and describes MDFlux as MarkItDown plus everything around it that makes the engine usable day to day. That framing matters for evaluating it: the extraction quality for born-digital PDFs, DOCX, PPTX, XLSX, EPUB, HTML, CSV, JSON, XML and plain text inherits whatever MarkItDown does, and MDFlux's own contribution sits in the surrounding layers. Those layers, as described, are OCR for scanned pages, batch processing across a folder, and an optional cleanup pass that tidies messy extraction output. The application shell is Tauri, with Rust and Svelte listed among the repository topics, while the primary language is Python. That combination implies a Rust/Svelte front end driving a Python conversion backend, though the supplied material does not document the boundary between them or how the Python side is packaged. The supported input list also includes images and audio, which the README lists in the format banner without explaining what Markdown output from an audio file looks like. That is a gap worth noting rather than glossing over.
Installing MDFlux: two editions and what the download actually contains
There is no pip install path documented in the supplied material. Distribution is through GitHub release archives. For Windows x64 there is MDFlux_0.3.0_windows_x64_full.zip and MDFlux_0.3.0_windows_x64_lite.zip. For Linux x64 with glibc there is MDFlux_0.3.0_linux_x64_glibc_full.tar.gz and MDFlux_0.3.0_linux_x64_glibc_lite.tar.gz. The README gives the size distinction explicitly: the Lite builds are 4.9 MB on Windows and 5.8 MB on Linux, and they download and install the required components when you first open the app. The Full builds bundle everything needed for document conversion and OCR in one download, so there are no additional MDFlux setup downloads on first launch. The README's own recommendation is to choose Full if you are unsure. The practical consequence of the Lite path is that first launch requires network access, which cuts against the offline claim for that edition specifically. If offline operation from the first run is the reason you are evaluating MDFlux, the Full archive is the one that matches that requirement. The README points to docs/cross-platform/releases-and-verification.md for verifying a download, and that is the step to take before running anything from a release archive.
The token comparison and where it stops being decisive
The README's central quantitative claim is roughly 4 times fewer tokens than vision for ordinary documents, and up to 5.7 times fewer on scanned pages. It supports this with a single table: a scanned image-only PDF yields 0 usable tokens from a plain text extractor, 10,731 from a vision model, and 1,893 from MDFlux OCR. The reasoning offered for why Markdown is cheaper is sound as far as it goes. Image inputs carry a fixed token cost per page independent of text density, Markdown is plain text without base64 payloads, and stripping broken layout and repeated whitespace removes tokens that carry no meaning. The caveat is that this comparison assumes the vision model is being charged for the page image on every read. If your pipeline converts a document once and stores the resulting text, the per-read multiplier the README leans on does not apply the same way; the saving is real but it is a one-time conversion cost, not a recurring one. Where MDFlux's argument is strongest is the scanned-PDF case, because a plain extractor genuinely returns nothing there and the alternative is OCR somewhere in the stack regardless. The README itself notes the vision model still has to OCR the image on its end, which is a fair point about duplicated work.
Platform support, editions and the gaps in the supplied documentation
The platform badge lists Windows and Linux (x64) only. Nothing in the supplied material mentions macOS, and the release asset names confirm the two-platform split. The Linux builds are specifically glibc, which excludes musl-based distributions such as Alpine without additional work that is not documented here. Beyond platform, several things a prospective adopter would want are absent from the material provided. There is no documented command-line interface, no Python API surface, no configuration file format and no config keys. If MDFlux is a GUI-only application, that is a real constraint for anyone who needs conversion inside a CI job, a container or a scheduled batch process on a headless machine. The README's batch feature is described as processing a folder, which suggests the batching happens inside the desktop app rather than through a scriptable entry point. The audio input format is listed but unexplained. The cleanup pass is described as optional but its mechanism and its failure modes are not documented in what was supplied. None of these are disqualifying, but they are the questions to resolve before committing a pipeline to this tool.
How MDFlux differs from calling MarkItDown directly
The obvious alternative is MarkItDown itself, which MDFlux is built on. The difference is what each one is. MarkItDown is a library: you call it from your own Python code and you own the surrounding logic. MDFlux is a packaged desktop application that adds OCR, folder-level batching and a cleanup pass, and ships as a signed release archive rather than an importable dependency. If your workflow is a Python service that already has an OCR step and a queue, MarkItDown plus your existing infrastructure gives you more control and no GUI. If your workflow is a person with a folder of PDFs who wants Markdown out the other end without writing code, MDFlux is the shorter path. There is also the vision-model route the README argues against, which remains the right call when layout fidelity matters more than token cost, for example when you need to preserve a complex multi-column table or a figure that carries meaning. Markdown conversion flattens visual structure into text conventions, and that is a lossy step by design. The README's own contrast with MarkItDown is explicit about the relationship, which is honest positioning rather than competitive framing.
Licence, maintenance and what upgrading costs you
MDFlux is MIT-licensed, and the README states it is free. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is a general description of the licence terms, not legal advice, and if you are embedding MDFlux or its output in a commercial product you should read the LICENSE file in the repository yourself. The maintenance picture visible in the material is a short release history: v0.1.0 in June 2026, v0.2.0 and v0.3.0 in August 2026, with the last push to the repository in September 2026. Three releases in roughly three months is an active but early cadence, and the version number confirms the project is pre-1.0. For a desktop tool that means interface and configuration changes between minor versions are plausible. Because MDFlux is built on MarkItDown, some of the upgrade cost is external: changes to the upstream engine's output format propagate into MDFlux's Markdown, which matters if you have downstream parsing that depends on specific heading or table conventions. Pinning a release archive and re-verifying against docs/cross-platform/releases-and-verification.md before upgrading is the concrete step that follows from that.
Editorial conclusion
Adopt MDFlux if you are on Windows or Linux x64, your documents are mostly born-digital or lightly scanned, and you want an offline conversion step before a retrieval or summarisation pipeline. Do not adopt it if you need macOS, a headless server-side converter, or a documented CLI and API surface, none of which the supplied material confirms. Verify two things first: the release checksum against docs/cross-platform/releases-and-verification.md, and whether the Full edition's bundled OCR components cover the languages and scan quality in your actual corpus.
Community notes