Convert LaTeX to Markdown

What is LaTeX?

LaTeX is a typesetting system born in 1984, written by Leslie Lamport on top of Donald Knuth's earlier TeX engine. It grew out of academic publishing — journals, mathematics textbooks, physics papers — where consistent output and precise control over equations, bibliographies, and cross-references mattered more than visual polish in an editor. Thirty years later, LaTeX still dominates disciplines that lean on heavy mathematical notation: mathematics, theoretical physics, econometrics, chemistry, quantitative biology, and large swathes of engineering. It also remains a default for PhD theses at many universities, which often publish LaTeX template repositories their students are expected to clone and fill in.

Outside academia, LaTeX is alive in niches: technical book authors using publishers like O'Reilly or Manning, Linux kernel documentation before .rst took over, and people who want reproducible PDFs from plain-text source under git. .tex files feel like source code rather than a document — commands are terse (\textbf, \cite), formatting decisions live in a preamble, and final output is produced by a compiler (pdflatex, xelatex, lualatex). You write content and macros; the compiler lays it out.

Why migrate to Markdown?

For most content that isn't a dense equation-heavy paper, Markdown is a better destination. Modern publishing targets — blogs (Jekyll, Hugo, Astro), documentation sites (Docusaurus, Nextra, VitePress), note-taking apps (Obsidian, Logseq), wiki platforms (GitHub Wiki, Notion), and newsletter tools — all speak Markdown natively. They do not speak LaTeX. If your goal is to turn a term paper into a blog post, or a thesis chapter into web documentation, or a set of tex-formatted research notes into a searchable Obsidian vault, you need the content out of .tex form.

Markdown is also better for collaboration with non-LaTeX users. GitHub renders MD inline in pull requests. Slack, Discord, and Telegram support Markdown in messages. Most journalists and bloggers can read and edit MD without a two-hour tutorial on environments and packages. Making the migration once, even losing some fidelity, usually saves more time than maintaining a LaTeX → HTML pipeline per-publication.

Markdown is not a replacement for LaTeX in academic math-heavy publishing. If you ship a 40-page paper to a conference that requires \input templates and specific bibliography styles, you stay in LaTeX. The migration case is about the content that doesn't need LaTeX's full power — everyday prose with the occasional formula.

Manual approach

Converting LaTeX to Markdown by hand is possible but tedious. Open the .tex file, copy the prose between \begin{document} and \end{document}, then walk through it replacing commands:

• \section{Title} becomes # Title
• \subsection{X} becomes ## X
• \textbf{x} becomes **x**, \textit{x} becomes *x*
• \begin{itemize} ... \end{itemize} becomes - bullet items
• \href{url}{text} becomes [text](url)
• $x^2$ can stay as $x^2$ if your MD renderer supports KaTeX / MathJax (GitHub, Docusaurus, Obsidian with plugin)
• \cite{key} has no native MD equivalent — leave as a placeholder and fix later

A 10-page LaTeX document takes 30–60 minutes to hand-convert if you are careful. The friction comes from small things: remembering that -- in LaTeX is an en-dash but MD treats it literally, that \\ is a hard line break, that ~ non-breaking space doesn't exist in Markdown. By the time you've processed the fifth section, you start making mistakes, and those mistakes compound. A \textbf{ without a matching } kills the rest of the conversion unless you catch it.

Where hand-conversion reliably breaks: tables (LaTeX tabular environments have column specs, \hline, \multicolumn, and & separators that all need translating to GFM pipe tables), citations and bibliography, custom \newcommand macros (expand them or fail), figures with complex captions, and any math beyond basic inline expressions. Expect to spend as long on three tables as on the rest of a 10-page document combined.

Automated approach (our tool)

Our converter implements the common-prose subset of LaTeX. You paste your .tex source and get Markdown out. The engine handles:

• Section headers: \section, \subsection, \subsubsection, and \title become #, ##, ###, and a top-level # respectively
• Inline formatting: \textbf, \textit, \emph, \texttt all map to their Markdown equivalents
• Lists: itemize becomes dash-bulleted lists, enumerate becomes numbered lists with sequential numbering preserved
• Code: verbatim environments become fenced code blocks (triple backticks)
• Math: inline $...$ and display $$...$$ equations are preserved verbatim, ready for any Markdown renderer with KaTeX or MathJax (GitHub, most doc sites, Obsidian)
• Citations: \cite{key} becomes [cite:key] — a placeholder you can post-process against your bibliography
• Links: \href{url}{text} becomes a Markdown link; \url{url} becomes an autolink
• Comments: % line comments are stripped so they don't pollute output
• Document boilerplate: \documentclass, \usepackage, \begin{document}, \end{document}, \maketitle, \author, \date all strip

What we deliberately do not cover: tabular environments, TikZ / PGF graphics, custom \newcommand macros, full bibliography (\bibliography, \bibitem), and structures that depend on specific document classes. If you try to paste a tabular block, our engine leaves it as literal text — better than silent corruption, but you'll have to hand-convert. For anything math-paper-complete, jump directly to Pandoc (see below).

Common gotchas

Math expressions going through unchanged. This is by design, not a bug. $E=mc^2$ arrives on the other side exactly as $E=mc^2$. Whether that renders as a pretty equation depends on the target platform. GitHub supports $...$ and $$...$$ inside Markdown; Obsidian does with the math plugin; Jekyll can with a KaTeX extension. If your target doesn't render dollar-delimited math, you need to post-process — wrap inline math in $$...$$ with explicit KaTeX blocks, or render equations to PNG before migrating.

Citations become placeholders, not links. \cite{einstein1905} becomes [cite:einstein1905]. This is intentional — we don't know what bibliography file you're using. If you're migrating a paper, resolve the citations yourself after conversion: search-and-replace each [cite:key] with a proper [Einstein 1905](#references) or equivalent.

Tables don't convert. LaTeX tabular supports column alignment specs ({l|c|r}), cell spans (\multicolumn), horizontal rules (\hline, \midrule), and vertical rules — all of which require interpreter-level parsing, not regex. Our engine leaves tabular blocks as literal text. Your options: (1) hand-convert the table to GFM pipes, (2) use Pandoc (which handles most tabular blocks), or (3) render the table to an image if perfect fidelity matters.

TikZ diagrams fail silently. TikZ is a graphical programming language for LaTeX. There's no Markdown equivalent — at all. If you had a circuit diagram or a graph drawn in TikZ, convert it to an image (render the .tex standalone, save the PDF page, convert to PNG/SVG) and embed the image in your Markdown.

Custom macros pass through as literal text. If your preamble defined \newcommand{\vec}{\mathbf} and you used \vec{x} in the body, our engine doesn't expand it. You'll see \vec{x} in the output. Pandoc handles some macro expansion; for simple cases, you can do it yourself with search-and-replace.

Accented characters via commands. \'e (acute e) or \"u (umlaut u) require a macro expansion step our engine skips. Pre-process your .tex file to convert these to their Unicode equivalents (é, ü) before pasting.

Comment lines stripped, but \% preserved. We intentionally do not strip \% because it's an escaped percent sign in the rendered output. Plain % to end-of-line becomes a stripped comment. If your source uses % as actual content (rare), wrap it in a command or escape it.

When to use Pandoc instead

Pandoc is the academic-grade tool for this job. It was written by John MacFarlane, it's been maintained for over fifteen years, and it supports a complete LaTeX parser with AST transforms into dozens of target formats. If your use case is any of the following, reach for Pandoc before our tool:

• Academic papers with bibliography, figure captions, and cross-references you need preserved
• Complete theses where tabular, figure, and subequations structures matter
• LaTeX-to-DOCX migrations for publishers who want Word output
• Anything that uses \input or \include to split across files

Pandoc requires a local install (brew install pandoc, apt install pandoc, or a binary download from pandoc.org). The basic invocation is pandoc paper.tex -o paper.md. For GFM output specifically: pandoc paper.tex -o paper.md -t gfm. Pandoc will produce higher-fidelity output than we do — proper table conversion, bibliography with -citeproc, image reference resolution. It's worth the setup cost when your input actually uses those features.

Our tool exists for the other half of the problem: quick paste-and-copy when you have a LaTeX fragment — a single section, a rough draft, a set of research notes — and don't want to install anything or think about -citeproc flags. For common-prose-with-math-and-lists, browser-based conversion is faster. For a 30-page journal submission, it is not.

Migration workflow

A pragmatic workflow for moving LaTeX content into a Markdown-based destination:

1. Identify the destination. A Jekyll blog, a Hugo site, an Obsidian vault, or a GitHub wiki all want slightly different things. Knowing the target helps decide what fidelity matters (GFM tables? KaTeX math? frontmatter?).
2. Separate heavy-LaTeX content from prose. Pull out the sections that are mostly English paragraphs and lists from the sections that are equations, tables, and figures. The prose goes through our tool cleanly. The heavy content either goes through Pandoc or gets hand-treated.
3. Paste the prose into our converter. Review the output — check that sections mapped correctly, lists look right, math expressions are preserved, citations became [cite:key] placeholders.
4. Resolve citations. If you maintain a .bib file, do a pass where each [cite:key] becomes a proper reference link. A small script can automate this if you have many refs.
5. Hand-treat tables or send them through Pandoc. Each table is its own small project. Decide whether you need a Markdown table, an HTML table (allowed in MD), or an image.
6. Convert diagrams to images. Render any tikzpicture standalone to PDF, convert to PNG or SVG, embed with ![caption](path).
7. Add frontmatter if your target needs it. Jekyll, Hugo, and Obsidian all have opinions about the YAML block at the top of each .md file — title, date, tags, layout. Add these manually.
8. Proofread the rendered output. Open the destination in preview mode. Spot-check math rendering, list nesting, link validity, image embedding. Expect to find two or three issues per page you'll want to fix.

For a 10-page LaTeX document, this workflow takes one to three hours of active editing, most of it on step 5 and step 8. The automated conversion itself is instantaneous. The value is in preserving the prose structure so you only have to touch the hard parts by hand.