LaTeXSnipper: A Desktop Formula Workspace Built Around a Managed Python Environment
Formula Recognition & Office Editing Math Workspace | Handwriting & PDF to LaTeX/Markdown, And Secure API Integrations.
At a glance
- What is it?
- LaTeXSnipper turns screenshots, PDF pages and handwriting into editable LaTeX, MathML or Word formulas, and exposes the same recognizer through a local Automation API. The interesting part is not the OCR model but the dependency layer it installs on your machine.
- Who is it for?
- Adopt LaTeXSnipper if you work on Windows with desktop Word or PowerPoint and need formulas inserted as editable OLE/OMML objects rather than pasted images, or if you want a local recognizer you can call from AutoHotkey, ShareX or a Python script. Do not adopt it if you need a headless Linux service, since the recognition path is a desktop app that installs a managed Python environment and downloads model weights, and Wayland may restrict screenshots and global shortcuts.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- 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 gap between a formula on screen and a formula you can edit
Copying a formula out of a PDF or a screenshot usually produces either an image or a run of Unicode characters that no equation editor will accept. LaTeXSnipper targets that specific gap. The README describes four input paths (capture a region, open an image, select PDF pages, write by hand) and a recognition step that returns formulas, text, or mixed content. The output is editable: the app ships a MathLive-based editor with live preview, and export covers 20 formats including LaTeX, MathML, Word, PDF and Typst. The audience is narrower than the feature list suggests. This is a desktop tool for people who already write in LaTeX or work inside Word equations: students, lecturers, researchers, and technical writers who keep hitting formulas they cannot retype. It is not a general document digitizer, and the README does not present it as one.
MathCraft OCR, external models, and where the weights live
Recognition runs through a model the project calls MathCraft OCR, and the README points to a separate repository (SakuraMathcraft/MathCraft-Models) for benchmark results and a reproduction guide under benchmarks/mathcraft_ocr/. That separation matters: the application repository does not carry the evaluation, so any accuracy claim has to be checked in the models repository rather than inferred from the app. The alternative path is to configure a local or online external model instead of MathCraft, which changes the deployment shape entirely. With an external model the app becomes a client, and the README warns that remote external-model access is separately controlled and may incur provider charges. The repository topics (im2latex, transformer, onnxruntime, pytorch, autoencoder) describe the model side, not the desktop shell, so treat the topic list as a hint about the recognition stack rather than a statement about how the app is packaged.
Installation is a two-stage process, and the second stage downloads weights
The README splits setup into installing the desktop app and then preparing recognition. On first launch you use Dependency Management to install the required layers and a CPU or GPU backend for MathCraft OCR, and the initial model setup requires downloading weights. If you only intend to use an external model, you skip that and configure and test the connection in Settings. Platform differences are explicit. Windows ships LaTeXSnipperSetup-<version>.exe with a bundled Python 3.11 template, so no system Python is needed. Linux gets a .deb for your architecture that declares python3 and python3-venv as dependencies, and you need Python >=3.10,<3.14 with venv and pip. macOS ships .dmg or .app.zip and also needs Python >=3.10,<3.14, plus Screen Recording permission for screenshots. On Linux and macOS, the system Python is used to create a managed dependency environment. That is the design decision to weigh: the app does not vendor a Python runtime outside Windows, so your distribution's Python version becomes an installation constraint.
The Office plugin is the part with no easy substitute
The Microsoft Office plugin targets Windows desktop Word and PowerPoint and inserts formulas as OLE/OMML objects with editable LaTeX source, rather than as static images. It also handles formula editing and updates, Word automatic numbering and references, and local formula rendering plus screenshot OCR through the desktop Automation API. It is a separate download (OfficePluginSetup-<version>.exe) and the README states support for 32-bit and 64-bit Office 2019/2021/2024, LTSC 2021/2024, and Microsoft 365 Apps on Windows. Two constraints are worth stating plainly. It is Windows-only, and it is version-gated to those builds. If your institution runs an older Office release or a non-Windows Word, this feature is unavailable to you and the rest of the app is just an OCR front end with export buttons.
The Automation API is off until you turn it on
The Automation API exposes the recognizer to scripts, batch jobs, editor integrations and authorized remote devices. The README is direct about the default: the API is disabled by default. Local clients read the address and token from automation-api.json. Remote access requires explicit opt-in, a separate key, and HTTPS or an encrypted tunnel, and the README says not to expose it over plain public HTTP. Documented integrations include Snipaste, AutoHotkey, AutoKey, Hammerspoon and ShareX for image recognition, Python and curl for batch submission, and Shortcuts or Tasker reaching a running desktop app through a secure tunnel. Note the shape of that last example: remote clients talk to a desktop app that must be running, not to a hosted service. There is an examples/automation/ directory with client examples and a docs/automation_api.md reference, so the integration surface is documented rather than implied.
Export formats depend on layers you install separately
Built-in exports cover LaTeX, Markdown math, MathML, HTML, Word OMML and SVG code, with no extra installation. Document exports such as Word, PowerPoint, EPUB, PDF and Typst require the optional Pandoc layer, installed through Dependency Management. PDF export additionally requires a LaTeX PDF engine, which the README does not name. That is a real gap if PDF is your target format: you will be resolving a TeX distribution question on your own. The layered approach keeps the base install smaller, but it also means the feature table in the README overstates what a fresh install can do until you add Pandoc and a PDF engine.
Wayland, Python versions, and the case against adopting it
The clearest limitation is stated in the platform table: on Linux, Wayland may restrict screenshots and global shortcuts. Capture Recognize is one of the four primary input paths, so on a Wayland session you may lose the fastest route into the app and fall back to opening image files. The Python range (>=3.10,<3.14) is another boundary; a distribution shipping Python 3.14 or newer, or a machine with no venv support, will need work before the managed environment can be created. The macOS build needs Screen Recording permission granted before screenshots function. If your requirement is a headless service that accepts images over HTTP and returns LaTeX, this is the wrong tool: the recognition path runs inside a desktop application that installs a managed Python environment and downloads model weights. Pandoc is the honest comparison for the export half of the story. Pandoc converts between document markup formats and can read LaTeX input, but it does not recognize formulas from pixels or handwriting, and it does not insert OLE objects into Word. LaTeXSnipper's Office plugin is the differentiator Pandoc cannot cover, and Pandoc's format breadth for document conversion is the part LaTeXSnipper only reaches by installing Pandoc as a layer. If your formulas already exist as text, Pandoc alone is the smaller dependency.
Licence, maintenance, and what to check before installing
LaTeXSnipper is GPL-3.0, and the repository is not archived. The most recent release in the supplied material is v3.0.0-LTS, dated 2026-09-07, one day before the last push to main. An LTS label on a 3.x release suggests the maintainers intend a stable line, but the README does not state a support window or a backport policy, so that reading is an inference, not a documented commitment. The project is described as a free, open-source, ad-free personal project with no in-app purchases, funded through sponsorship and donations, and the supporter list names two contributors and two sponsors. That is a small maintenance base. For GPL-3.0, the practical question for a company is whether distributing the app internally or bundling it into a product triggers source obligations; that is a question for your own counsel, not something this review can settle. Before installing, confirm the version numbers of your Office build, your Python interpreter, and your display server, because each of those three can block a feature the README advertises.
Editorial conclusion
Adopt LaTeXSnipper if you work on Windows with desktop Word or PowerPoint and need formulas inserted as editable OLE/OMML objects rather than pasted images, or if you want a local recognizer you can call from AutoHotkey, ShareX or a Python script. Do not adopt it if you need a headless Linux service, since the recognition path is a desktop app that installs a managed Python environment and downloads model weights, and Wayland may restrict screenshots and global shortcuts. Before committing, verify four things: that your Python is within >=3.10,<3.14 on Linux and macOS, that the MathCraft OCR layers and a CPU or GPU backend install cleanly through Dependency Management, that the Office plugin covers your Word or PowerPoint build (the README lists Office 2019/2021/2024, LTSC 2021/2024 and Microsoft 365 Apps on Windows), and that the Automation API token in automation-api.json is reachable from whatever client you plan to wire up.
Community notes