asciimathml renders AsciiMath notation as MathML with one script tag

A translator from calculator-style notation to native MathML

The idea behind asciimathml is that mathematics should be writable as plain text. ASCIIMathML.js is described in the README as a compact JavaScript program that translates simple calculator-style math expressions on a webpage to MathML, and the resulting page can be displayed with any browser that can render MathML.

That last clause is the significant design decision. The output is MathML rather than an image, a font file or a LaTeX rendering, so the browser's own maths engine handles layout and accessibility. The cost is that the input language is not LaTeX, it is AsciiMath, a notation designed to be typed by hand in a few characters.

The audience is anyone who needs to publish mathematics on a web page and does not want to run a LaTeX compiler in the publishing pipeline. That covers documentation sites, course notes, blog posts with equations, and small internal tools. The runtime cost is the point in favour: the script runs in the reader's browser, and the repository describes the original as compact.

The repository itself is described as a new home for asciimathml, and the syntax documentation lives at AsciiMath.org rather than in this tree. That distinction matters when you are looking for support, since the parser and the notation specification are maintained in different places.

One script tag, and expressions between backticks

The integration is deliberately minimal. The README says to load the script in the head or body of your website, with the tag written as `<script src="ASCIIMathML.js"></script>`. There is no build step and no configuration file for the basic case.

The default behaviour is automatic conversion on page load, which grabs any expressions between backticks. The README's example is a sentence containing an inline expression, the pattern being Solve followed by a backticked x/2+3=5. The convention is familiar from forum and chat markup, which is why the notation works well in prose.

The configuration is inside the script itself, as the README states: you adjust it in the file rather than through options passed at load time. That is the right call for a single page and the wrong call for a site that ships the same script on many pages with different needs, where you would end up maintaining several copies of the file.

The key point for a reviewer is that this is page level transformation. The script walks the document and rewrites matching text into MathML nodes in place, so the result is visible in the DOM and in the page source after the script runs. Any content added to the page later by other code is not converted unless something calls the API for it, which is what the node level function is for.

Three API entry points, from whole page to single expression

The README documents a small API on top of the automatic behaviour, and the three functions cover three different granularities.

The first is asciimath.translate(), which converts all asciimath on the page. That is the manual version of what happens automatically on load, and it is the one to call after you have inserted content dynamically.

The second is asciimath.AMprocessNode(node), which converts any asciimath delimiters inside the given HTML node. The signature is what makes it useful, because it takes a DOM node rather than a string, so you can scope the conversion to one element, for example a comment or a section that you have just re-rendered.

The third is asciimath.parseMath(string), which takes an AsciiMath string and returns a MathML node. This is the function to reach for when you are building the expression yourself rather than finding it in the document, for example from a form field or from data.

The split matters when you compare this with the TypeScript build described later in the README, because the browser bundle keeps the equivalent asciimath.AMprocessNode and asciimath.parseMath functions, while the server bundle keeps only a parseMath that returns a string instead of a DOM node. If you are writing code that runs in Node, the node based function is not available to you, and that difference decides which bundle you need.

The TypeScript build has a browser target and a Node target

The ts/ directory holds a TypeScript implementation, and the README is clear that it is an alternate implementation of the core AsciiMath parsing rather than a wrapper around the original script. The important limitation is stated plainly: it does not implement the autotranslation and autodetecting features.

So the two implementations are not interchangeable. The original ASCIIMathML.js scans the page on load and converts what it finds, while the TypeScript core parses an expression you hand it. If you want the original behaviour you use ASCIIMathML.js; if you want programmatic parsing in a build script or a server, you use the TypeScript build.

The build produces two artefacts from that source, and the npm scripts show how. The browser bundle is built with esbuild from ts/Parse.ts, bundled as an IIFE with the global name asciimath:

    "build": "esbuild ts/Parse.ts --bundle --format=iife --global-name=asciimath --target=es6 --outfile=dist/asciimathml.js",

The server bundle comes from a different entry point, ts/ParseToString.ts, and is emitted as an ES module for Node:

    "buildserver": "esbuild ts/ParseToString.ts --bundle --format=esm --target=es6 --outfile=dist/asciimathml-server.js",

The target of es6 in both commands is worth noting for anyone serving these to older browsers, and the two different formats reflect the two environments. A watch script and a TypeScript compile step exist alongside them, plus a typecheck script, and the only devDependencies are esbuild and typescript, so the build itself is small and has no runtime dependency to ship.

LaTeXMathML.js only converts what LaTeX itself would convert

The second script in the repository root, LaTeXMathML.js, is described as similar to ASCIIMathML but with one significant difference: it only converts expressions that LaTeX would convert.

That single sentence tells you what the script is for and where it will let you down. It is a converter for LaTeX style input, not a general maths renderer, and expressions that LaTeX would reject, or would treat differently, are left alone. If you have an existing corpus of LaTeX snippets and want them rendered as MathML in the browser, this is the file to load instead of ASCIIMathML.js, and if you are writing new notation by hand, AsciiMath is the syntax to write.

The two scripts sit side by side in the repository root, along with AUTHORS.MD and the LICENSE file, and they are loaded in the same way, with a script tag in the head or the body. Nothing in the README describes a way to combine them, and loading both on one page is not documented, so treat the choice as a decision between two files rather than a configuration choice.

The underlying specification for the notation is documented at AsciiMath.org, and it is worth checking against whatever your existing maths content uses, because that is where the edge cases live.

asciimath-based holds converters to TeX, and the wider ecosystem sits outside

The asciimath-based/ directory contains alternate implementations of AsciiMath parsers, and the README points to the README inside that directory for the details. Two entries are named. ASCIIMath2TeX.js is a JavaScript script with functions to convert AsciiMath notation to TeX, and it can also be imported into Node. ASCIIMath2TeX.php is a PHP port of that, doing the same conversion in PHP.

The direction of conversion is the interesting part. ASCIIMathML.js goes from AsciiMath to MathML, and these go from AsciiMath to TeX, which is the route you need when the target is a LaTeX based publishing pipeline rather than a browser. Reading the same notation into two very different outputs from one repository is a sensible way to keep a shared notation consistent across a document set.

The README then lists other implementations done by other people, and it is careful about them: they have not been evaluated by this repo for compatibility, accuracy, or anything else. The list includes a JavaScript AsciiMath to TeX library with npm support and ES6 modules, a Ruby parser and MathML and TeX generator, a .NET converter, a PHP implementation, and two TypeScript implementations. The disclaimer is the important part. Those projects are pointers, not endorsements, and the repository makes no claim about how they compare on accuracy or on which AsciiMath features they cover.

MIT licensed, npm published, but with no tagged releases

The licensing is simple. The package.json records the MIT licence, and the LICENSE file sits in the repository root next to ASCIIMathML.js, LaTeXMathML.js and the AUTHORS.MD file. MIT is permissive enough that embedding the script in a commercial site raises few questions beyond keeping the notice.

The package is published to npm under the name asciimathml, and the manifest records the version as 2.6.1 along with a description of ASCIIMathML scripts with a typescript implementation. The package is not marked private, so it is intended for consumption, and the repository root holds a package-lock.json, a test/ directory, the dist/ directory with the built bundles, the ts/ source, and separate tsconfig.json and tsconfig-esm.json files for the two compilation targets.

The gap worth noting is the release trail. The repository has no GitHub releases at all, and the last push was on 2026-07-11. Tags and the npm version are therefore the only version markers available, and there is no changelog in the root listing to tell you what changed between versions. For a script that people embed directly in a page, that is a tolerable position, since the file is small and easy to read, and it is a real one for a dependency you would otherwise install from npm without reading.

Editorial conclusion

Adopt asciimathml if you want to write mathematics in a plain text notation and have browsers render it as native MathML without pulling in a LaTeX toolchain, and if you can live with the fact that the project publishes no tagged releases. Do not adopt it as a general LaTeX replacement, since LaTeXMathML.js only converts what LaTeX itself would convert, and do not adopt it if you need a maintained package with a versioned release trail, since the npm package exists without GitHub releases. Before you use it, read the note in the ts/ directory, because the TypeScript implementation deliberately drops the automatic translation and detection that the original script has, and decide which of the two implementations your page needs before you copy a script tag into it.

Frequently asked questions

Official sources

1. asciimath/asciimathml on GitHub
2. Issues
3. License: MIT
4. Project website
5. README