MathLive: three web components, a separate server build, and an unpinned CDN tag

Three components, and one of them replaces a function you used to call

The library ships three custom elements and the division between them is a performance decision, not an aesthetic one. The editor is a math field element, and it is the heavyweight: it provides text-area-like interfaces including a value, a selection and a command execution method, it emits input and change events, and it carries a full virtual keyboard with customisable layouts. Then there are two static renderers, both of which avoid that cost. An inline element renders math inside a paragraph, and a block element renders display equations, and the readme is explicit about who the block one is for: anywhere you previously called a document-wide render function on a page. That sentence is a migration note, and it tells you the library is aimed at people moving off an approach where a script walked the document and turned delimiters into rendered output. In the new model you mark up the maths in the document, which means the markup is the source of truth and a stylesheet or a script failure degrades to readable source rather than to an unrendered mess. Both static components take LaTeX by default and accept two alternative formats, an ASCII maths format and a JSON format, they expose a mode attribute for inline versus display styling, and they provide an imperative render method for when you change content programmatically. So the choice is: pay for an editor where a person types, or pay almost nothing where a formula is read. The install is one command and the import is one line, and the editor element then looks like this in a page:

<math-field virtual-keyboard-mode="auto" smart-fence>f(x)=x+1</math-field>

Lazy fonts once, and defer rendering until the formula is on screen

Two sentences in the static component description are a page-performance strategy, and they are worth reading as engineering rather than as a feature list. The shared fonts are lazy-loaded once, and rendering is deferred until the element is visible, detected with an intersection observer. Together they solve the two problems that make a maths page slow. A page of technical writing can easily contain hundreds of formulas, and a maths font is a large file with many glyphs; loading it once and sharing it across every instance avoids a request per equation. And a formula below the fold does not need to be typeset until someone scrolls to it, which is the single biggest win on a long article because the initial render cost drops to what is actually visible. The lazy loading also means the font arrives after first paint, so there is a moment where the maths is set in a fallback face. The library is not hiding that: it also provides a mode attribute and an imperative render method, so if the flash matters for your design you can control when typesetting happens. The accessibility consequence is bundled into the same design. The elements generate ARIA labels with speech-friendly text automatically, which is the mechanism that makes a rendered formula announceable, and it is the reason a static renderer here is not just a drawing call.

Accessibility is a feature, and auto-generated labels are a compromise

The subtitle of the project is web components for math input, display and accessibility, and that third word is not decoration. The feature list names screen-reader friendliness, math-to-speech, and ARIA labels, and the static components auto-generate those labels with speech-friendly text. For a maths editor, this is the difference between a usable application and an unusable one, because almost every learner-facing use of a maths input is assistive-technology use. The compromise is worth naming honestly. A label generated from the expression is a mechanical rendering of the notation, and a human author writing for a screen reader would phrase things differently: they would expand a symbol, add a word, or describe the structure in a way a listener can follow. An auto-generated label cannot know the intent. So the right way to think about it is that the generated label is a floor, not a ceiling, and if your application has a screen-reader expert in it, they should be reviewing what the library produces rather than assuming it is finished. The same reasoning applies to the speech output, which is a synthesis of the expression rather than a recording of how a person would read it aloud. This is a case where a feature that is automatic in the best case and mechanical in the worst case still beats no support at all, and the library is honest about shipping it as the default rather than as an option.

The export map carries five conditions, including a separate server build

The package manifest is where the integration details live, and there are three that will save you time. The first is the stylesheet. The exports map exposes the font stylesheet and the static stylesheet as named subpath entries, which means they are not injected by the JavaScript and not bundled with it. You import the component bundle and you also import a stylesheet, and if you forget the second one you get mathematics rendered with the wrong metrics and no error message. That is a two-minute mistake with a confusing symptom, and the fix is one import. The second is server-side rendering. The exports map has a condition for the Node environment pointing at a different bundle and, importantly, a different type definition file, plus a separate server subpath entry. So this component library has a dedicated server build rather than a browser bundle that fails in a server process, and the types differ too, which means the typings you get depend on where your code runs. The third is the development and production split inside the browser condition: a bundler in development mode receives the unminified build and in production mode the minified one, without you configuring anything. Worth noting alongside these is the maintenance detail. Every script in the manifest delegates to a shell script, so building, testing, cleaning and starting the documentation all require a bash shell, which is a real constraint on a contributor on Windows.

The manifest is ten minor versions ahead of the newest release tag

Compare two numbers in this project and they do not agree. The newest release tag is 0.100.0, published on 2024-06-12. The version in the package manifest is 0.110.0. The repository is not archived and the last push was on 2026-09-11. So the default branch carries ten minor versions that no release tag corresponds to, which is a much larger gap than a normal pre-release state and points to a release process that has moved somewhere other than GitHub tags, or to a cadence that has slipped. The readme answers the question directly in its own frequently-asked section, and the answer is a policy rather than a date. The project states a semi-annual cadence with major drops around June and January, plus patch releases for regression fixes, and it says that sponsor requests or community pull requests can trigger out-of-band releases when needed. Read the first half as the plan and the second half as the mechanism, and the second half has a consequence for anyone depending on the library: the timing of your upgrade is partly a function of sponsorship and of individual contributions, not only of a published schedule. If you need predictable releases, the tag list is the wrong thing to plan against, and the funding arrangement is the thing to be aware of. There is also a maintenance badge in the header, and it reads 2025, which is consistent with a project whose peripheral metadata lags its source.

The documented CDN line has no version in it

One line in the quick start is worth reading twice, because it is a supply-chain decision rather than a documentation one. The readme shows loading the library from a content delivery network by adding a deferred script tag whose source is a package on a public CDN:

<script defer src="https://cdn.jsdelivr.net/npm/mathlive"></script>

There is no version, no tag and no integrity hash in that URL. A script tag with no version requests whatever the current published version is at the moment the page loads, which means a page using that line changes behaviour whenever the package is republished, with no deploy and no diff in your repository. That is acceptable for a demonstration and wrong for production, and the fix is trivial: pin the version, and add a subresource integrity attribute so the browser refuses a file that does not match. The readme does not mention either. The same instinct appears elsewhere in the project, in the lazy font loading and the deferred rendering, so the authors clearly think about page weight and load behaviour. It is worth noting that the package is namespaced rather than bare, so the CDN path is not vulnerable to a name collision with an unrelated package, which is one of the usual arguments for the bare-specifier style. Pinning the version and adding the integrity hash is the remaining half of the practice, and it is a five-minute change in your own page rather than a limitation of the library.

Two identities: the editor on one domain, the interchange format on another

The project has a sibling you only notice when you follow the links. The readme's framework guides and its related projects are hosted on a different domain from the component library, and the related projects live under a different GitHub organisation. The format itself, a lightweight data interchange format for mathematical notation, is a separate project from the editor, and so is a companion project that performs numeric and symbolic calculation on expressions in that format. So there are two artefacts with two release cycles: the component library, and the interchange format every other tool must also implement. That separation is the right design, because a format that a single company's editor controls would be a vendor format, and it means you can round-trip through it with any implementation. It also means a question you should ask is whether the format or the editor is the thing that must be stable for you, because they will not move together. The format list in the features section is broader than the usual maths component story: input and output are supported as LaTeX, MathML, ASCII maths, Typst and the JSON format. MathML is the accessibility-oriented interchange, ASCII maths is the text fallback, and Typst is a modern typesetting system rather than a TeX dialect, so the library both consumes and emits a format that a TeX-only lineage would not. The repository also carries two changelog files, one for recent changes and one covering a period ending in 2023, which dates the project to around 2017 and explains the accumulation of peripheral files, including a legacy continuous integration configuration sitting next to a modern browser-testing configuration.

Editorial conclusion

Adopt MathLive if you need editable mathematics in a browser rather than rendered mathematics, because the editor, the virtual keyboards, the speech output and the screen reader labels are the parts you would otherwise build, and the static components handle the read-only case without the editor overhead. Do not adopt it for a static maths site, where a rendering-only library with a much smaller footprint is the right answer, because the editor brings the keyboard and speech machinery with it. Two things to check before you adopt. Read the release policy rather than the release list, because the manifest is at 0.110.0 while the newest tag is 0.100.0 from 2024-06-12, and the stated cadence of major drops in June and January with out-of-band releases on sponsor request means your upgrade path is partly a function of someone else's funding. And import the stylesheet, because the package exposes its fonts and static styles as separate subpath exports and forgetting them gives you unstyled mathematics rather than an error.

Frequently asked questions

Official sources

1. arnog/mathlive on GitHub
2. License: MIT
3. Project website
4. README
5. Releases