Overview

LaTeX Math Reference

Look up any LaTeX math command, environment, or symbol: what it renders, which package defines it, and whether MathJax, KaTeX, and XeTeX support it.

This section is a reference to the LaTeX that TeXForm understands: every command and environment it can parse, which package each belongs to, the argument structure it expects, and how it renders across MathJax, KaTeX, and XeTeX. You can use it without using TeXForm at all — it answers "what arguments does \frac take?" or "does KaTeX support \dv?" on its own.

Try

Browse by topic#

Topics group every entry by what it does — arrows, accents, matrices, physics derivatives — whichever package defines it. Each topic page lists its entries in one table with their packages, renderer support, and corpus frequency.

Common commands#

The commands that appear in the most corpus formulas, with the share of formulas that use each. The command index lists every command with filters for topic, package, and renderer support.

Renderer coverage#

Each command and environment is rendered against three real engines from generated test cases. Symbols are single characters and are not render-tested. KaTeX's gaps are concentrated in the physics and bboldx packages, which it does not implement; renderer support breaks the counts down by package and lists the most frequent gaps.

MathJaxReference renderer622 full · 2 partial · 6 none
KaTeXCompatibility target317 full · 13 partial · 300 none
XeTeXCompatibility target485 full · 18 partial · 127 none

Catalog#

The same catalog at four granularities. Start from a package to browse by source, or from the command, environment, and symbol indexes to search and filter across all packages.

How the reference is built#

Coverage is defined by the knowledge base, not by hand-maintained lists. TeXForm parses against machine-readable argument specifications for the commands and environments in the supported packages — base, ams, physics, braket, bboldx, boldsymbol, and textmacros. Every entry in this reference is generated from those same specifications, so what you read here is exactly what the parser uses. An entry's argument structure is written as an xparse-style argspec such as m m or o m; see reading argspecs for the notation.

The data is checked by rendering, not by transcription. Each argument specification is turned into representative test cases and rendered against three real engines; an entry's renderer support reflects what those engines actually accepted. How entries are built and verified is described in the knowledge base.