FormaTeX

\begin{comparison}

How to Render LaTeX Equations
for the Web

Server-side APIs, client-side JavaScript, or a hybrid approach? This guide compares every major method for rendering LaTeX equations as images or HTML — so you can pick the right one for your website, documentation, or application.

\section{methods overview}

Three approaches to rendering LaTeX equations

Every LaTeX equation renderer falls into one of three categories. The right choice depends on where the equation will be displayed, whether the content is static or dynamic, and how much you care about typographic fidelity.

Server-side rendering

API call returns an image (PNG, SVG, or PDF)

You send your LaTeX source to a REST API and receive a rendered image in the response. The equation is compiled on the server using a real TeX engine, so the output is identical to what you would get from a local TeX Live installation. The result is a static asset you can embed anywhere: HTML pages, emails, Markdown files, Slack messages, or presentation slides.

Examples: FormaTeX API, CodeCogs, QuickLaTeX, i2svg

Advantages

  • Pixel-perfect output from a real TeX engine
  • Zero client-side JavaScript required
  • Works in emails, PDFs, Markdown, and any HTML
  • Consistent rendering across all browsers and devices

Trade-offs

  • Requires a network request per equation
  • Latency depends on server response time
  • May need an API key for production use

Client-side rendering

JavaScript library renders equations in the browser

A JavaScript library (MathJax or KaTeX) parses LaTeX syntax directly in the browser and converts it to HTML/CSS or SVG nodes in the DOM. No server round-trip is needed after the initial page load. This approach works well for interactive applications where equations are entered by the user in real time, such as forum editors, notebook interfaces, or live preview tools.

Examples: MathJax, KaTeX

Advantages

  • No server dependency after the JS bundle loads
  • Instant rendering for user-typed equations
  • Good for interactive or real-time editing UIs

Trade-offs

  • Adds JavaScript bundle weight (KaTeX ~28 KB min+gz, MathJax ~100 KB+)
  • Does not cover the full LaTeX language (only math mode)
  • Rendering can vary slightly between browsers
  • Cannot be used in emails or non-HTML contexts

Hybrid approach

Server renders, client displays cached images

Equations are compiled server-side at build time or on first request, then cached as static images and served from a CDN. The client loads pre-rendered images with no JavaScript and no runtime compilation. This combines the typographic quality of server-side rendering with the performance of static assets. It is the recommended approach for documentation sites, blogs, and any page where equations do not change after publishing.

Examples: FormaTeX API + CDN cache, pre-built static sites

Advantages

  • Best of both worlds: TeX-quality output with zero client JS
  • Equations are cached and served at CDN speed
  • SEO-friendly with alt text on images

Trade-offs

  • Requires build-time or first-request compilation step
  • Not suitable for user-entered equations at runtime

\section{server-side}

Server-side renderers compared

Four services that compile LaTeX on a server and return an image or vector. Each has a different scope: some handle only math mode, while others run a full TeX Live installation capable of compiling entire documents.

FormaTeX API

Full TeX Live compilation via REST API. Supports complete LaTeX documents (not just equations), three engines (pdfLaTeX, XeLaTeX, LuaLaTeX), and output in PNG, SVG, or PDF. Designed for developers who need programmatic access to a real TeX compiler without managing TeX Live infrastructure.

CodeCogs

One of the oldest LaTeX-to-image services. You construct a URL with your LaTeX math expression as a query parameter, and the server returns a PNG or GIF. Simple to use for single equations in Markdown or HTML. Limited to math mode only and does not support custom packages or document compilation.

QuickLaTeX

A free web service primarily used as a WordPress plugin. Accepts LaTeX via a POST endpoint and returns PNG images. Supports a limited subset of LaTeX packages beyond basic math. Good for bloggers and WordPress users, but lacks a documented REST API for programmatic integration.

i2svg

A lightweight service that converts LaTeX math expressions to SVG via URL parameters. SVG output scales infinitely, making it useful for responsive web designs. However, it only handles math mode, has no REST API, and does not support custom packages or full document compilation.

FeatureFormaTeXCodeCogsQuickLaTeXi2svg
Output formatsPNG, SVG, PDFPNG, GIF, SVGPNGSVG only
Full LaTeX supportFull TeX LiveMath mode onlyLimited packagesMath mode only
Custom packagesAll CTAN packagesNoLimited subsetNo
Multiple enginespdfLaTeX, XeLaTeX, LuaLaTeXpdfLaTeX onlypdfLaTeX onlyNone (JS-based)
REST APIYes, documentedURL-based onlyPOST endpointURL-based only
DPI / resolution controlConfigurableLimited presetsConfigurableVector (infinite)
Rate limits (free tier)15 compilations/monthUnclear / throttledUnclearUnlimited (self-hosted)
Commercial API plansFrom $4.99/monthCustom pricingFree onlyOpen source

= strong = adequate = not supported

\section{client-side}

Client-side renderers

MathJax and KaTeX are JavaScript libraries that render LaTeX math notation directly in the browser. They do not compile full LaTeX documents — they handle math mode only. For many web applications, this is exactly what you need.

MathJax

The most widely used client-side math renderer. MathJax supports a very broad subset of LaTeX math commands, including AMS extensions, and can output to HTML/CSS, SVG, or MathML. It is the default math renderer for many wikis, LMS platforms, and scientific websites.

Best for

  • Websites that need broad LaTeX math coverage
  • Platforms already using MathJax (migration cost is zero)
  • Accessibility — MathML output works with screen readers
  • Complex equations including multi-line environments

Watch out for

  • Bundle size: ~100 KB+ minified and gzipped
  • Initial render delay on large pages with many equations
  • Configuration can be complex for advanced setups

KaTeX

A fast, lightweight alternative to MathJax created by Khan Academy. KaTeX renders synchronously, meaning equations appear in the same paint frame as the rest of the page. It supports a smaller subset of LaTeX math than MathJax, but covers the vast majority of common use cases.

Best for

  • Performance-critical applications (renders 10x faster than MathJax)
  • Live-preview editors where typing latency matters
  • Server-side rendering with Node.js (KaTeX can run on the server)
  • Smaller bundle size (~28 KB minified and gzipped)

Watch out for

  • Narrower LaTeX support — some AMS environments are missing
  • No MathML output (accessibility is limited)
  • Custom macros require extra configuration

When to use client-side rendering instead of an API

Client-side renderers are the right choice when equations are user-generated at runtime, when you need instant preview during editing, or when you want to avoid server costs entirely. They work well in single-page applications, interactive textbooks, and any interface where the user types LaTeX and expects to see the rendered output immediately.

However, if your equations are static (known at build time), if you need output beyond math mode (full documents, custom packages, TikZ diagrams), or if you need to embed equations in non-HTML contexts (emails, Slack, PDFs), a server-side renderer is the only option. The FormaTeX equation-to-image tool handles all of these cases.

\section{decision matrix}

Which approach is right for you?

The answer depends on your use case. Here is a quick reference for the most common scenarios.

Blog or documentation site with pre-written equations

Server-side (hybrid with CDN cache)

Equations are known at build time. Compile once, cache forever. Zero client JavaScript. Best page performance and SEO.

Web application with user-entered math (e.g., forum, homework tool)

Client-side (KaTeX for speed, MathJax for coverage)

Users type equations in real time. Client-side rendering gives instant feedback without waiting for a server round-trip.

Email newsletters or Slack/Discord bots

Server-side (image output)

Email clients strip JavaScript entirely. You need a static image. A server-side renderer like FormaTeX API returns a PNG you can embed directly in the email body.

Academic PDF generation via CI/CD pipeline

Server-side API (FormaTeX or self-hosted TeX Live)

Full TeX Live compilation produces publication-quality PDFs. The FormaTeX API handles this with a single POST request, no Docker TeX Live image required.

Presentation slides (reveal.js, Google Slides)

Server-side (SVG or high-DPI PNG)

SVG equations scale perfectly at any resolution. Render server-side, download the image, and insert it into your slide deck.

Jupyter-style notebook in the browser

Client-side (KaTeX or MathJax)

Notebooks need instant rendering as users type. KaTeX is faster for common math; MathJax covers more obscure TeX commands.

Rule of thumb

If your equations are known ahead of time (documentation, blog posts, generated reports), use a server-side renderer and cache the output. If your equations are typed by users at runtime (forums, notebooks, live editors), use a client-side library. If you need both, the hybrid approach gives you TeX-quality images for static content and instant client-side rendering for interactive features.

One quick thing

We track anonymous usage — page views, feature usage, compilation events — to understand what works and what doesn't. No ads, no personal data, no third-party sharing.

Cookie policy