How to Convert Markdown to PDF with LaTeX Equations That Don’t Break

To convert Markdown with LaTeX equations reliably, protect math before normal Markdown parsing, render it with a compatible math engine, wait for rendering to finish, and apply page-aware sizing to the result. This prevents Markdown syntax from damaging equations and prevents wide formulas from being clipped in the PDF.

The difficult cases are not $x^2$. They are matrices, AMS environments, macros, chemistry, MathML, long expressions, currency-like dollar signs, and malformed equations inside a long document.

For the broader workflow, read the complete Markdown-to-PDF guide.

Why do LaTeX equations break during Markdown-to-PDF conversion?

Markdown and TeX reuse several punctuation characters. A Markdown parser may interpret underscores as emphasis, asterisks as emphasis or list markers, backslashes as escapes, and brackets as links.

If the parser changes the source before the math engine receives it, the math engine cannot reconstruct the original equation.

This problem is visible in real user questions. A Stack Overflow question about exporting matrices from VS Code described partial success with MathJax injection but continued failure for array and eqnarray-style content.

What is the safest parsing order?

The safest order is:

1. Detect math delimiters and environments in the original source.
2. Exclude inline code and fenced code from math detection.
3. Replace math blocks with protected placeholders.
4. Parse the remaining Markdown.
5. Restore and render protected math.
6. Wait for the math renderer to finish.
7. Fit the rendered result within the printable page width.

This order keeps TeX source away from transformations intended for prose.

Which math delimiters should a converter recognize?

Technical Markdown commonly uses several conventions:

Which math delimiters should a converter recognize?

Type	Common delimiters
Inline math	$...$
Inline math	\(...\)
Display math	$$...$$
Display math	\[...\]
Environment	\begin{align}...\end{align} and related AMS forms

Supporting all four delimiter styles reduces friction when documents come from different editors.

A converter should also distinguish inline math from currency. Text such as $5, $125.00, and US$20 should not automatically become an equation.

Why should code blocks be excluded from math rendering?

Code documentation often contains literal strings such as $PATH, \(pattern\), \[index\], or TeX examples. Rendering those strings as math corrupts the code sample.

The rule should be simple:

• math delimiters in prose can be rendered;
• math delimiters inside inline code remain source;
• math delimiters inside fenced code remain source.

Which LaTeX environments matter for technical documents?

A practical technical renderer should test more than equation.

Common environments include:

• equation and equation*;
• align, align*, aligned, and alignat;
• gather, gathered, and starred variants;
• multline;
• flalign;
• split;
• cases;
• matrix and array environments.

Matrices and multi-line derivations are frequent failure points because they contain alignment characters, line breaks, and nested delimiters.

MathJax or KaTeX: which should you use?

Both engines are useful. The choice depends on required syntax, rendering behavior, and deployment constraints.

The VS Code Markdown PDF extension currently documents KaTeX-based math support. Typora documents MathJax-based math, chemistry, equation numbering, and cross-reference features. This difference illustrates why two “Markdown with math” workflows may support different commands or environments.

SolConverter currently uses MathJax SVG because its target documents include:

• AMS environments;
• MathML;
• chemistry;
• broad MathJax packages;
• document-scoped macros;
• equations that need scalable vector output.

Do not present this as proof that one engine is universally better. Test the actual syntax your users submit.

Why render equations as SVG?

SVG remains sharp when the PDF is zoomed or printed. It also provides a measurable box that can be constrained to the printable width.

However, “scale to fit” is not enough for every expression. Shrinking a very long equation until it fits can make it unreadable.

A better strategy is:

1. identify top-level additive operators;
2. split the expression into logical lines;
3. preserve mathematical order;
4. render each line as vector math;
5. fit the resulting block to the page.

How should a converter handle an extremely long equation?

A long additive expression should wrap at top-level + or - operators when possible. It should not split inside a fraction, matrix, group, subscript, or function argument.

SolConverter’s current test fixture includes an 84-term expression that is split across lines without dropping a term. Treat that number as a dated product test, not as a universal maximum.

Recommended public test format:

• publish the exact Markdown input;
• show the generated PDF page;
• state page size and margins;
• state renderer version and date;
• verify that all terms remain present;
• include a machine-readable output check where possible.

What should happen when an equation is malformed?

A malformed equation should not automatically destroy a long document.

A localized recovery policy can:

• catch the error at the block;
• display the original source in a neutral fallback;
• continue rendering the rest of the document;
• record the error in job diagnostics.

SolConverter currently removes a surplus closing brace only when the remaining expression is otherwise balanced. It does not guess a missing closing brace. This is a conservative policy: correct obvious local damage without inventing mathematical structure.

How should macros and labels be isolated?

Math engines can keep state across renders. If a backend reuses a browser or renderer, a macro or label from one user’s document must not leak into the next export.

Reset or isolate:

• custom macros;
• equation labels;
• counters;
• renderer configuration;
• document-specific extensions.

SolConverter scopes macro, label, and equation state to each document and tests repeated exports for leakage.

Can Markdown-to-PDF support MathML?

It can, but support levels differ.

SolConverter currently supports:

• Presentation MathML;
• basic Content MathML operations.

Do not describe this as full MathML coverage without a formal conformance suite.

Can chemistry be rendered in Markdown PDF?

Yes, when the math engine and extension support it. Typora documents chemistry expressions through the mhchem extension. SolConverter currently supports \ce{...} through its MathJax configuration.

Example:

\ce{2H2 + O2 -> 2H2O}

How do you stop equations from splitting across pages?

Display equations should be treated as print blocks. CSS can request that the browser avoid breaking them across pages.

This is a preference, not an absolute guarantee. If the rendered equation is taller than the printable page, the browser must either scale, overflow, or split it. Test unusually tall matrices and derivations separately.

Test fixture for Markdown math

Use a fixture containing all of the following:

Inline math: $E = mc^2$

Currency: $5, $125.00, and US$20

Display math:

$$
\int_{-\infty}^{\infty} e^{-x^2}\,dx = \sqrt{\pi}
$$

Matrix:

\[
\begin{bmatrix}
1 & 2 \\
3 & 4
\end{bmatrix}
\]

Aligned equations:

\begin{align}
a &= b + c \\
d &= e + f
\end{align}

Chemistry:

$\ce{CH4 + 2O2 -> CO2 + 2H2O}$

Code must stay literal:

`$not_math$`

```text
\[
This must remain source.
\]
```

Add one malformed equation before a valid equation to confirm that rendering continues.

Current SolConverter math support

The verified renderer currently supports:

• $...$, $$...$$, \(...\), and \[...\];
• common AMS environments;
• matrices, arrays, calculus, linear algebra, probability, physics notation, and chemistry;
• MathJax SVG;
• Presentation MathML and basic Content MathML;
• document-scoped macros;
• long additive-expression wrapping;
• RTL isolation for math;
• source fallback for malformed input.

Current non-claims include full TikZ, full siunitx, full tikzcd, AsciiMath, Typst math, and complete LaTeX cross-references.

Frequently asked questions

Why does my matrix render in preview but not in PDF?

The preview and PDF export may use different renderers or may snapshot the page before math finishes. Confirm that the export path uses the same math engine and waits for completion.

Does Markdown officially support LaTeX?

Markdown itself does not define one universal math syntax. Math support is provided by the editor, parser extension, converter, or rendering engine.

Can MathJax equations remain sharp in PDF?

Yes. SVG-rendered math remains vector-based and scales cleanly.

Should a converter repair broken LaTeX automatically?

Only conservatively. It can correct narrowly defined, unambiguous damage, but it should not invent missing mathematical structure.

Can I use macros?

Yes, when the renderer enables them. In a multi-user backend, macros must be scoped to one document.

Next step

Use a real equation fixture before choosing a converter. Include matrices, environments, macros, chemistry, currency, code samples, and a deliberately malformed block.

Convert Markdown with math to PDF or learn how large-document failure isolation works.

References

• Typora: Math and Academic Functions
• Markdown PDF - Visual Studio Marketplace
• Pandoc User’s Guide: Math
• Stack Overflow: How to export Markdown to PDF with a math matrix
• MathJax Documentation