mdtopdf.

Document field notes

LaTeX math in Markdown that survives the PDF

A pre-export workflow for inline and display equations, including a small sampling fixture and a PDF inspection pass for roots, fractions and limits.

Published 2026-10-24 · Markdown to PDF editorial

Math is the part of a Markdown document most likely to look right in a preview and wrong in the file you send. Fractions, roots and limits are laid out by a renderer, then rendered again when the page is printed to PDF. Check the downloaded file itself, at full size, before you attach it to anything.

What the converter documents

Markdown to PDF lists LaTeX math among its features, and its public product notes describe inline math in $…$, display math in $$…$$, and output emitted as MathML so the PDF needs no extra fonts. That is the product's own description. It is not a promise that every LaTeX command or layout will match a dedicated typesetting system.

In a desktop browser check on 24 October 2026, the live preview produced two MathML <math> elements for the fixture below: the inline expression and a block-level display expression. The product notes and that observation are the basis for this workflow. The PDF export test described later is a single check of one document, not a benchmark.

A fixture worth keeping

A short sampling note exercises the constructs that most often change shape: an inline estimator, a display formula with a fraction, a square root, a sum and subscripts.

# Sampling notes

Inline: the estimator is $\hat{\mu} = \frac{1}{n}\sum_{i=1}^{n} x_i$ for a sample.

Display:

$$
\mathrm{RMSE} = \sqrt{\frac{1}{n}\sum_{i=1}^{n}(y_i - \hat{y}_i)^2}
$$

A price like \$5 and a range $3 to $7 should not become math.

Keep an unchanged copy of the source next to the exported PDF. When an equation looks wrong, you need to know whether the Markdown changed, the preview changed, or only the print layout changed.

What the exported file showed

The fixture was pasted into the converter and downloaded as a one-page PDF on 24 October 2026. The equations were present as text rather than missing glyphs, and a text extraction returned the symbols and variables. Rendered at 300 dpi, however, the display formula's nested root and fraction were visibly more compressed than in the preview, with uneven spacing around the radical. The inline expression was closer to the preview but still not identical.

Treat that as a reason to inspect, not as a defect report. One export, one browser and one PDF renderer cannot establish how every viewer will draw every expression. The practical conclusion is narrower and more useful: the preview is a layout approximation, so the PDF is the artifact you have to check.

Write equations you can verify

  1. Choose inline or display deliberately. Use $…$ for a symbol inside a sentence and $$…$$ for an equation that deserves its own line. Display math is easier to inspect and less likely to disturb line spacing.
  2. Escape literal dollar signs. CommonMark permits a backslash before any ASCII punctuation, so \$ produces a literal dollar sign. In the browser check, an escaped \$5 stayed as text. An unescaped $5 and $7 also happened to stay literal in that renderer, but do not rely on that: escape prices and other currency explicitly.
  3. Put words inside \text{…}. Without it, a word in math mode is treated as a product of italic variables. In the check, \text{rate} rendered upright inside the equation, while the same command written outside the dollar signs stayed literal.
  4. Use aligned for multi-line derivations. A display block containing \begin{aligned}…\end{aligned} rendered as one equation with the alignment points honoured. Splitting a derivation into several separate display blocks makes page breaks harder to predict.
  5. Keep display math contiguous. A blank line inside $$…$$ still produced a single math block in this renderer, but that is a parser detail, not a guarantee. Writing each display block without internal blank lines keeps the source portable to other Markdown tools.
  6. Watch the failure modes that stay quiet. An unmatched $ stayed literal in the preview, and an unknown command such as \notarealcommand{x} appeared inside the equation as literal command text rather than stopping the page. Both are easy to miss when you are skimming.

Inspect the PDF in four passes

  1. Notation pass. Read every equation in the PDF, not the preview. Check that the radical covers the intended terms, that fraction bars sit between the right numerator and denominator, and that limits and subscripts are attached to the correct symbol.
  2. Selection pass. Select an equation and copy it into a plain-text editor. Extraction does not prove visual correctness, but it reveals whether the symbols exist as text and whether words inside \text{…} survive.
  3. Page-edge pass. Look at the widest equation at the page boundary. A display line that fits the preview pane can still run past the printable width. Split the expression with aligned rather than shrinking the whole document.
  4. Print pass. Print one page in greyscale, or preview it at 100% in a second viewer. MathML and embedded fonts can look different at small sizes; a symbol that is merely thin on screen can disappear on paper.

Diagnose an equation that changed

The dollar signs appear in the PDF
The expression was not recognised as math. Check for an unmatched delimiter, a missing closing $, or a line break placed inside an inline expression. Keep inline math on one line.
A command name appears as text
The renderer does not know that command. Replace it with a supported construct, or spell the quantity out in prose. Proofread for stray backslashes as well.
The equation is cramped or uneven
Nested roots, fractions and limits are the first places layout diverges. Simplify the expression, split it across aligned lines, or state the result in prose and keep the full derivation in an appendix.
A symbol is missing in one viewer
Try a second PDF viewer before editing the source. If the symbol is absent in both, rewrite the expression using a more common construct. This check does not certify font coverage or accessibility.
Currency became math
Escape the dollar signs as \$. A pair of currency amounts can otherwise be read as a math delimiter pair by some parsers.

Delivery checklist

  • Inline math stays on one line; display math has its own blank lines around the block.
  • Literal dollar signs are escaped, and words inside equations use \text{…}.
  • Multi-line derivations use aligned rather than several unrelated display blocks.
  • The downloaded PDF has been read at 100%, not only the live preview.
  • Every root, fraction, limit and subscript has been checked against the source.
  • Text extraction, page edges and one greyscale print have been inspected.
  • Key results are repeated in prose where a reader may not be able to select the equation.

Sources and scope

Checked 24 October 2026. The workflow is editorial guidance. The browser and PDF observations come from one desktop session and one one-page export on that date; no benchmark, cross-viewer audit or accessibility certification is claimed. The downloaded PDF was inspected with a text extractor and a 300 dpi raster render, and opened in a browser PDF viewer.