What TeXForm is

Programs that process LaTeX formulas — cleaning OCR training data, comparing formulas for equivalence, preparing pretraining corpora, building math editors — keep reinventing the same fragile layer: regular expressions and one-off heuristics that guess what \frac, \over, or \quantity mean. The hard part was never the string manipulation. It is knowing the argument structure of every command well enough to work on formulas as syntax trees instead of text.

TeXForm is that layer. It parses a formula against a structured knowledge base of command and environment specifications from the supported LaTeX packages, hands you an editable tree, and normalizes formulas into canonical forms tuned for specific downstream uses. One Rust core, available in Rust, Python, and JavaScript.

Thirty seconds of it looks like this — a physics macro that only renders with that package loaded, turned into a universal form that any renderer accepts. physics is not in the default package set, so the engine's knowledge base names it:

import texform

kb = texform.KnowledgeBase(packages=["base", "ams", "physics"])
engine = texform.TransformEngine(profile="corpus", knowledge_base=kb)
print(engine.normalize(r"\dv{f}{x}"))

\frac { \mathrm { d } f } { \mathrm { d } x }

import { KnowledgeBase, TransformEngine } from 'texform';

const knowledgeBase = new KnowledgeBase({ packages: ['base', 'ams', 'physics'] });
const engine = new TransformEngine({ profile: 'corpus', knowledgeBase });
console.log(engine.normalize('\\dv{f}{x}'));

\frac { \mathrm { d } f } { \mathrm { d } x }

Three pillars#

Everything in TeXForm sits on three assets, and each one is a page in these docs:

• A knowledge-driven parser. Formulas parse into real syntax trees because the parser reads each command's argument signature from a curated knowledge base rather than guessing from syntax. Unknown commands and unparseable fragments survive as explicit nodes under your control, never as a crash. See Parsing.
• An editable document tree. Parsing produces a Document: a DOM-style tree you query, mutate, and serialize back to LaTeX. Edits are validated and return structured errors, and the serializer guarantees text idempotency, so its output parses and serializes back to the same string. See Serialization.
• A profile-based transform engine. Normalization has no single correct answer, so TeXForm never imposes one true form. You pick a profile that names your downstream use — authoring, render-faithful, corpus, or equivalence — and a curated rule pipeline produces the canonical form for that use. Every rule declares its rule level, its worst-case fidelity, and the forms it eliminates, and the engine enforces that contract after every run. See Transforms.

Two of those assets did not exist as reusable artifacts before: the argspec knowledge base, whose signatures are validated by rendering against MathJax, KaTeX, and XeTeX rather than transcribed from documentation, and the curated rewrite rule set with its enforced eliminated-form contract.

The unit of work is a formula#

TeXForm works on math formulas, not on LaTeX documents. There is no notion of sections, bibliographies, floats, \usepackage, or a preamble; you hand it the contents of a math environment and it hands back the contents of a math environment. Packages are how the knowledge base is organized, not something your input declares.

That is a scope decision, not a limitation to be lifted later. Whole-document conversion is a genuinely different problem with different tools — LaTeXML and plasTeX live there. Keeping the unit of work at formula scale is what makes it reasonable to demand a real knowledge base for every command, an idempotency guarantee on the output, and contract checking on every rewrite.

Why not an existing tool#

The tools people already reach for each cover part of this job:

• General LaTeX parsers give you a tree, but decide command arguments from a built-in table, from signatures you write, or by attaching the groups that follow, so package commands such as \dv{f}{x} often come out as a name followed by loose groups.
• Renderers know commands well enough to display them, but produce HTML, SVG, or MathML rather than LaTeX you can store, edit, or compare.
• Normalization scripts in OCR and evaluation code rewrite tokens or strings, so they pass unknown commands through unchanged and cannot tell you when a formula was not understood.

How TeXForm compares goes through these tools job by job, including when one of them is the better choice.

Where renderers and CAS tools fit#

TeXForm's relationship to MathJax and KaTeX is easy to misread, so it is worth stating both directions.

Upstream, they validate the knowledge base. Every argspec is checked by rendering it against MathJax, KaTeX, and XeTeX, which is how an entry earns the coverage status you see on the LaTeX reference pages. That validation is internal tooling; it is not something TeXForm does at runtime. See Renderer validation.

Downstream, they display the output. TeXForm emits a LaTeX string, and a renderer turns that string into something a reader sees. It does not embed, wrap, or replace a renderer, and there is no plugin to install. The practical connection is that Faithful and Corpus normalization expand package-specific macros into universal forms, so, with the physics package loaded, a formula written with commands such as \dv or \ket becomes a formula a vanilla MathJax or KaTeX deployment can render with no extra packages.

For mathematical meaning, the partner is a computer algebra system. The Equiv profile canonicalizes equivalent spellings to the same string, which resolves a large share of notation noise with a plain string comparison — but a formula whose equivalence is mathematical rather than notational needs SymPy or a similar tool. Compare formulas shows that two-layer workflow.

What TeXForm does not do#

Three boundaries are worth stating plainly, because each one saves you from asking TeXForm for the wrong thing:

• It does not compute mathematical equivalence. TeXForm canonicalizes notation; it does not know that x + x equals 2x. Normalize with TeXForm first, then hand the result to a CAS.
• It does not render. TeXForm emits LaTeX, never pixels, HTML, or MathML. Fidelity levels are contracts its rules declare, not comparisons it runs.
• It is not a document processor. The unit of work is a formula. Sections, bibliographies, and floats are out of scope by design.

Use TeXForm when you need to parse, edit, and normalize LaTeX math as structured syntax with command-level knowledge, and compose it with a CAS or a renderer when your task crosses into mathematical meaning or visual output.