LaTeXSnipper: turning screenshots, PDFs and handwriting into editable formulas
Formula Recognition & Office Editing Math Workspace | Handwriting & PDF to LaTeX/Markdown, And Secure API Integrations.
At a glance
- What is it?
- LaTeXSnipper is a GPL-3.0 desktop workspace that recognizes formulas and text from images, PDFs and handwriting, then lets you edit and export them. The interesting part is not the OCR, it is the local MathCraft runtime and the disabled-by-default Automation API.
- Who is it for?
- LaTeXSnipper fits people who retype formulas from papers, lecture slides or scanned homework and want the result as editable LaTeX or OMML rather than a picture. It does not fit anyone who needs a headless server-side OCR pipeline with no GUI, or who cannot install a Python 3.10 to 3.13 environment on Linux or macOS.
- 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 received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem LaTeXSnipper actually targets
Copying a formula out of a PDF usually gives you either an image or a run of garbled glyphs. Retyping it into LaTeX by hand is slow and error-prone, and the result is often needed inside Word or PowerPoint rather than in a .tex file. LaTeXSnipper is built for that loop: capture a region, open an image, select PDF pages, or write by hand, then get back formulas, text, or mixed content that you can edit and export.
The audience is narrow and fairly specific. It is a desktop application with packages for Windows, Linux (Debian/Ubuntu .deb) and macOS (.dmg or .app.zip). There is an Office plugin for Windows desktop Word and PowerPoint, and an Automation API for scripts and batch jobs. Someone who only needs to OCR a folder of images once and never touch a GUI will find the desktop-first shape of the project awkward, but a student or researcher assembling notes from screenshots is exactly who the README addresses.
Recognition, editing and export as three separate stages
The architecture splits cleanly into recognition, an editing workspace, and export. Recognition has two possible engines. The first is MathCraft OCR, which runs locally after you download dependencies and weights; the second is an external model, local or online, that you configure and test in Settings. The README presents these as alternatives rather than a fallback chain, and says that if you use only an external model you configure its connection instead of installing the local layers.
Editing happens in a math workspace built on MathLive with live preview, where the README says you can simplify, evaluate and solve expressions. Export then covers 20 formats, including LaTeX, MathML, Word, PDF and Typst. The repository layout reflects this split: mathcraft_ocr/ holds the OCR runtime, src/ the application, office_plugin/ the Word and PowerPoint integration, and examples/automation/ the API client examples.
The OCR runtime itself is packaged separately in pyproject.toml as mathcraft-ocr, version 0.3.1, described as an "ONNX-only OCR runtime for mathematical documents". Its dependencies include numpy, pillow, opencv-python, rapidocr, transformers and tokenizers, with onnxruntime variants selected through optional extras: cpu, gpu, gpu-cu12, directml, openvino, dev and pandoc. That structure matters if you plan to use the runtime outside the desktop app, because the backend is a deliberate install-time choice, not something the package picks for you.
Installing LaTeXSnipper and running a first recognition
The README gives a three-step path: install the desktop app from Releases, prepare recognition on first launch through Dependency Management, then recognize and edit. The package names differ by platform: LaTeXSnipperSetup-<version>.exe on Windows, a .deb per architecture on Debian/Ubuntu, and a .dmg or .app.zip on macOS.
On Windows, the installer bundles a Python 3.11 template, so no separate system Python is required. On Linux and macOS the app uses system Python to create the managed dependency environment, and the requirement is Python >=3.10,<3.14 with venv and pip. The .deb declares python3 and python3-venv as dependencies, so a Debian or Ubuntu install pulls them in. The README's download table names the Linux package as a .deb for your architecture and does not print an apt command, so install it the way you install any local .deb.
After the app starts, the first real task is recognition setup. On first launch you use Dependency Management to install the required layers and a CPU or GPU backend for MathCraft OCR. The README states that initial model setup requires downloading weights, so the first run is not offline. If you only want an external model, you skip that and configure and test the connection in Settings instead.
Once recognition is ready, the workflow is Capture Recognize, Image, PDF or Handwriting, followed by review, copy or export. The Automation API is the scriptable version of the same recognition step, and it is disabled by default. Local clients read the address and token from automation-api.json, and the README points to docs/automation_api.md for the API reference and to examples/automation/ for ready-to-adapt Python and curl clients. Neither the port number nor the exact endpoint path appears in the README, so take both from those files rather than guessing at request shapes.
Where LaTeXSnipper gets in the way
The most concrete limitation is environmental. Linux and macOS builds do not ship a Python runtime; they create a managed environment from the system interpreter, which must be at least 3.10 and below 3.14. A machine pinned to an older or newer Python needs a second interpreter installed before recognition works at all. The .deb is Debian/Ubuntu-specific, so other distributions are on their own for packaging.
Wayland is a second constraint the README names directly: it may restrict screenshots and global shortcuts. That hits the capture workflow, which is the primary way many people would use the tool, and there is no documented workaround in the README.
PDF export is conditional rather than built in. The README says document exports such as Word, PowerPoint, EPUB, PDF and Typst require installing the optional Pandoc layer in Dependency Management, and that PDF export additionally requires a LaTeX PDF engine. So "export to PDF" is really a two-dependency feature.
Finally, the API is off by default, and remote access is deliberately gated: explicit opt-in, a separate key, and HTTPS or an encrypted tunnel. The README warns against exposing it over plain public HTTP. That is the right default, but it also means the API is not a zero-configuration path to remote recognition. Remote external-model access is controlled separately and may incur provider charges.
How it compares with a plain OCR pipeline
A general OCR tool such as Tesseract, wired into a script, will read text from an image and hand you a string. It has no formula model, no editing workspace, no Word OMML insertion, and no built-in export matrix. If your input is prose, that difference does not matter, and a small script around Tesseract is easier to run headless on a server.
LaTeXSnipper takes the opposite approach: a PyQt6 desktop application (PyQt6 6.10.0 and PyQt6-Fluent-Widgets in requirements.txt) with a purpose-built math OCR runtime, a MathLive editing surface, and 20 export formats. The trade-off is that you get a GUI process, a dependency-management step, downloaded weights, and platform-specific packaging instead of a single command-line binary.
The Automation API narrows the gap but does not close it. It lets scripts, batch jobs and editor integrations submit images and get results, and the README lists Snipaste, AutoHotkey, AutoKey, Hammerspoon and ShareX as desktop shortcuts that can be pointed at an image-recognition workflow. What it does not offer is a documented server deployment: the API belongs to a running desktop app, and remote devices connect to it through a secure tunnel. If your requirement is "run this in a container on a build machine", the project is the wrong shape.
Licence, maintenance and upgrade cost
LaTeXSnipper is licensed under GPL-3.0, and the separately packaged mathcraft-ocr runtime declares GPL-3.0-only in pyproject.toml. If you embed either in a distributed product, the copyleft terms apply to the combined work, so the licence is a real constraint for closed-source shipping rather than a formality. This is a description of what the files say, not legal advice.
On maintenance, the repository is not archived, and the last push was on 2026-09-08. The most recent release is v3.0.0-LTS, published on 2026-09-07. Those dates indicate recent activity, but they say nothing about how long any given release line will be supported; the README does not document a support window for the LTS tag.
Upgrade cost is dominated by the model layer. The pyproject.toml pins exact versions for several dependencies, including rapidocr==3.5.0, transformers==4.55.4 and tokenizers==0.21.4, and the requirements.txt file pins the application stack the same way (PyQt6==6.10.0, Pillow==12.3.0, PyMuPDF==1.27.2.2). Pinned dependencies make reproducibility easier and version bumps more deliberate. The README does not document rollback or downgrade steps, so a release that changes model weights or the managed environment should be tested on a copy of your setup before you replace a working install.
The Office plugin is a separate install with its own constraints
Formula insertion into Word and PowerPoint is not part of the main installer. You download OfficePluginSetup-<version>.exe separately from Releases. The README states support for 32-bit and 64-bit Office 2019, 2021 and 2024, LTSC 2021 and 2024, and Microsoft 365 Apps on Windows. There is no macOS or Linux Office support described.
The plugin covers Word OLE/OMML and PowerPoint OLE/PNG insertion with editable LaTeX source, formula editing and updates, Word automatic numbering and references, and local formula rendering plus screenshot OCR through the desktop Automation API. That last point is the coupling to watch: the plugin's OCR path runs through the desktop app's API, so the desktop application has to be present and running for that part of the workflow. Installation requirements and formula workflows live in office_plugin/README.md and docs/office_plugin_formula_workflows.md.
Editorial conclusion
LaTeXSnipper fits people who retype formulas from papers, lecture slides or scanned homework and want the result as editable LaTeX or OMML rather than a picture. It does not fit anyone who needs a headless server-side OCR pipeline with no GUI, or who cannot install a Python 3.10 to 3.13 environment on Linux or macOS. Before committing, check the Dependency Management panel on your machine, confirm that MathCraft OCR weights download and load on your chosen backend, and read docs/automation_api.md if you intend to call the API from scripts, because the API is disabled by default and remote access needs its own key plus HTTPS or an encrypted tunnel.
Frequently asked questions
What is LaTeXSnipper used for?
It converts screenshots, images, PDF pages and handwriting into editable formulas and text. The README lists recognition, editing with live preview, export to 20 formats including LaTeX, MathML, Word, PDF and Typst, and integration with Word, PowerPoint and scripts through the Automation API.
Which platforms does LaTeXSnipper support?
The README lists Windows, Linux and macOS, with a .exe installer, a Debian/Ubuntu .deb and a .dmg or .app.zip respectively. Windows bundles a Python 3.11 template, while Linux and macOS require system Python >=3.10,<3.14 with venv and pip.
Does LaTeXSnipper need an internet connection to recognize formulas?
Not for recognition itself if you use the local MathCraft OCR engine, but the README states that initial model setup requires downloading weights. If you configure only an external model instead, recognition depends on that model's connection, and the README notes remote external-model access may incur provider charges.
Is the LaTeXSnipper Automation API enabled by default?
No. The README states the API is disabled by default, that local clients use the address and token in automation-api.json, and that remote access requires explicit opt-in, a separate key, and HTTPS or an encrypted tunnel rather than plain public HTTP.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/sakuramathcraft-latexsnipper)