Getting Math Rendered in Your Jupyter Cells

Jupyter uses LaTeX by default for mathematical notation, but it doesn't always behave the way you expect when you first try it. The most common mistake I see is people typing LaTeX directly into a regular markdown cell without wrapping it in dollar signs, then wondering why it just shows raw symbols instead of a rendered equation. You need to switch the cell type to Markdown first. Click the cell, then go to the menu bar and select Cell > Cell Type > Markdown, or just press M while the cell is selected. Once you're in Markdown mode, wrap your LaTeX in single dollar signs for inline math or double dollar signs for display mode. For example, typing $E = mc^2$ in a markdown cell renders the equation inline with the surrounding text, while putting it between double dollars on its own line gives you a centered, standalone equation. The trick is that Jupyter uses MathJax under the hood, not KaTeX. That matters because MathJax supports a much broader set of LaTeX packages and environments than KaTeX does. You can use things like \begin{pmatrix} and \begin{cases} without any extra configuration, which is a relief since matrix notation and piecewise functions come up constantly in technical work.

Here's a quick example that actually works when you run it. Put this in a markdown cell: $$\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}$$ Press Shift+Enter and it renders as a proper integral. The backslashes before x^2 are essential — without them Jupyter treats the caret as a literal character instead of an exponent operator inside the LaTeX parser.

I ran into a problem last year where I was writing out a long set of coupled differential equations and the rendering was completely broken. The issue turned out to be curly braces inside the align environment. LaTeX requires you to escape literal curly braces when they appear inside certain environments, but Jupyter's preview doesn't always flag this clearly. The error message is subtle — the equation just doesn't render at all, which makes debugging frustrating because you have to manually scan through the entire block to find the unescaped brace. My workaround was to write the equations in a plain text editor first, validate the LaTeX syntax there using an online checker, and only then paste it into the notebook. It added a step but saved me from spending twenty minutes trying to spot a single missing backslash. For inline equations that appear within paragraphs, keep them on the same line as your text. Single dollar signs work here: the quadratic formula is $x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$ and it flows naturally with the sentence. Don't use double dollars for inline math — it forces the equation onto its own line and breaks your layout. Greek letters follow standard LaTeX conventions. Alpha is $\alpha$, beta is $\beta$, and theta is $\theta$. Uppercase versions are just capitalizing the command, so $\Gamma$ gives you Gamma. There's no separate list to memorize for the most common ones, but obscure symbols like \eth or \hbar might not render consistently depending on your MathJax version, so stick to the well-supported characters for anything meant for publication.

Get the Full Details

Writing Math Equations in Jupyter Notebook: A Naive Introduction
Writing Math Equations in Jupyter Notebook: A Naive Introduction

One thing people consistently miss is that Jupyter's markdown preview in the browser behaves slightly differently from the exported HTML. I've had equations look perfect in the notebook but come out malformed when I export to HTML or PDF. The fix is to use nbconvert with the correct flags and test the output rather than assuming the live preview is accurate enough for final formatting. If you're doing a lot of math notation, consider installing the jupyter-contrib-nbextensions package. It adds a toolbar with shortcuts for common LaTeX operations like subscripts, superscripts, fractions, and Greek letters, which cuts down the time spent looking up syntax from minutes per equation to just clicking a button. The extension isn't necessary, but it prevents the kind of syntax fatigue that leads to those escaping-brace disasters I mentioned. There are limits to what works well in Jupyter's markdown cells. Large equation blocks with dozens of lines can cause the page to freeze briefly while MathJax re-renders, especially on older machines. I once had a notebook with a very long derivation that would take about eight seconds to load each time I reopened it. Splitting the content across multiple cells and using collapsible sections helped reduce the pain, though the underlying issue is just MathJax's rendering pipeline and there's no real fix for it beyond upgrading hardware or simplifying the equations.

Another common pitfall is mixing Python code and LaTeX in the same cell. They don't interact, which sounds obvious but trips people up when they try to reference a Python variable inside a LaTeX expression. The markdown cell won't evaluate Python, so if you need to embed a computed value in an equation, you have to use f-strings or format the number in a code cell first and then copy it into the markdown cell as static text. When you're done writing your equations and want to share the notebook, make sure you export using the right format for your audience. PDF exports preserve the LaTeX rendering well, while HTML exports rely on the reader's browser having MathJax loaded, which is almost always the case but not guaranteed in restricted environments. For internal documentation where everyone has the same browser setup, HTML is fine. For anything going external or to people who might open it offline, PDF is more reliable.