§ Markdown to PDF API

Markdown to PDF API: Convert Markdown to a Real, Styled PDF

Turn markdown into a searchable, branded PDF from your own code with one API call. Render the markdown to HTML with the library you already use, style it with your CSS, and let managed Chromium produce the PDF, no LaTeX toolchain to install and no headless browser to run and scale yourself. Paste any HTML in the demo below to see the output.

Early access, launching soon
No card required
Your HTML stays yours

§ Live demo

Runs in your browser. Nothing is uploaded.

Sample Page size Orientation Margins

Your HTML

Live preview

Your PDF is downloading. Want this as one API call, with the page archived too?

§ Short answer

To convert markdown to PDF in production, render the markdown to HTML with a markdown library (marked or markdown-it in Node, python-markdown or markdown-it-py in Python, or pandoc -t html), then send that HTML to a browser to lay out and print. Sitepdf runs that final step in managed Chromium and returns a true, searchable vector PDF with your own CSS applied, plus an optional timestamped archive of exactly what it rendered. Pandoc with a LaTeX engine gives the best typography for books and papers, but it is a heavy install and CSS control is awkward; the HTML plus browser path wins when you want the PDF to match a web design and to run at scale without a browser in your own process.

Last updated July 2026. Written and fact checked by the Sitepdf team.

§ 00

Three ways to convert markdown to PDF, compared

Every markdown to PDF pipeline is really a choice of what does the final layout: LaTeX, a browser you host, or a browser someone else hosts. That choice decides your install size, how much CSS control you get, and whether you can scale it.

Approach	How it works	Typography and CSS	What you run	Best for
Pandoc + LaTeX CLI	pandoc md to PDF through a LaTeX engine (xelatex, tectonic)	Superb typesetting, but CSS does not apply and tables need tinkering	A full LaTeX install (hundreds of MB) on every machine	Books, papers, dense technical docs rendered locally
Local Chromium md-to-pdf, Pandoc + WeasyPrint	markdown to HTML, then a local headless browser or WeasyPrint prints it	Full CSS control, web fonts and tables just work	You install, run and scale the browser or WeasyPrint yourself	CI jobs and local scripts on one machine
HTML + rendering API Sitepdf	Your markdown library makes HTML, you POST it, managed Chromium prints it	Full CSS control, real current browser, selectable text	One HTTP call, no browser or LaTeX in your stack	Production apps rendering markdown at scale, plus a dated record

The honest read: if you are producing a book or an academic paper on your own laptop and want the finest line breaking, Pandoc with a LaTeX engine is hard to beat and costs nothing. If you want the PDF to look like a web page, keep full CSS control, and turn user-submitted or generated markdown into branded PDFs at scale without babysitting Chromium, render the HTML in a browser and let a service host it.

§ 01

Markdown never converts to PDF directly, and that is the whole trick

There is no single jump from markdown to a PDF. Markdown is a text format, PDF is a page format, and something has to do the layout in between. Almost every tool bridges that gap in one of two ways: it hands the markdown to a typesetting engine like LaTeX, or it turns the markdown into HTML and asks a browser to print the page. Once you see that, the choices stop feeling arbitrary. LaTeX gives you beautiful typography but ignores CSS, so a design that matches your web app is painful. A browser gives you every bit of CSS you already write, which is usually what a product team actually wants.

The HTML route is the one most Node and Python apps land on, because you almost certainly already have a markdown library. In Node, marked or markdown-it turns a string into HTML in a couple of lines. In Python, markdown or markdown-it-py does the same, and pandoc -t html works from any language. You wrap that HTML in a template with your stylesheet, and now the only thing left is to print it. That last step is the part that is genuinely hard to run well yourself, which is where an API earns its place.

§ 02

The production pipeline: markdown to HTML to a real PDF

Here is the whole flow in Node. You render the markdown to HTML, drop it into an HTML shell with your CSS, and post that to the render endpoint. The browser lays it out exactly as it would on screen, so your headings, code blocks, tables and web fonts all match your site, and the text in the PDF stays selectable and searchable.

import { marked } from "marked";

const body = marked.parse(markdownString);
const html = `<!doctype html><html><head>
  <link rel="stylesheet" href="https://yoursite.com/pdf.css">
</head><body class="prose">${body}</body></html>`;

const res = await fetch("https://api.sitepdf.com/v1/render", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.SITEPDF_KEY}` },
  body: new URLSearchParams({ html, format: "Letter", archive: "true" }),
});
const { pdf_url } = await res.json();

Two details save you time. First, link or inline the CSS in the HTML you post, because the markdown library only gives you the body markup, not your styles. Second, if your markdown contains code blocks you want highlighted, run your syntax highlighter (Prism, highlight.js, Shiki) over the HTML before you send it, since the browser will honor whatever classes and CSS you include. The same call works from Python or any language that can make an HTTP request; our HTML to PDF in Python guide shows the requests version, and the PDF generator API page lists every parameter, including margins, page size and headers.

§ 03

When Pandoc and a LaTeX engine are the right call

We are not going to tell you the API is always the answer. If you are producing a long document where typographic quality is the point, a technical book, a thesis, a math-heavy paper, then Pandoc with a LaTeX engine such as xelatex or tectonic produces output that a browser cannot match on fine line breaking, hyphenation and equation setting. It is free, it runs offline, and for a document you build once on your own machine that is often exactly right. The price is the install: a full LaTeX distribution is hundreds of megabytes, and getting your own CSS or brand design into the output means learning LaTeX templates rather than writing the HTML and CSS you already know.

So the rule is about what the document is. A styled report, invoice, release note or knowledge-base export that should look like your web design, generated on demand for many users? Render the HTML in a browser. A carefully typeset book or paper you compile yourself and where LaTeX quality matters more than CSS? Pandoc plus LaTeX. Trying to run either LaTeX or your own headless Chromium inside a busy web server, under load, is the path that quietly turns into an operations problem, which is the reason teams reach for a hosted render step. The convert HTML to PDF page covers that trade off in general, and the HTML to PDF in Node.js guide compares running Puppeteer yourself against calling an API.

§ 04

Keep a dated copy of every document you generated

Markdown to PDF is often the last step in something that matters: a signed agreement rendered from a template, a generated report sent to a client, a compliance note archived for the record. No CLI or library keeps a copy for you once the file leaves. Add archive=true to the render call and Sitepdf also stores a timestamped, immutable snapshot of exactly what it rendered, retrievable by id later, so you can prove what a given document said on a given date. The website archiving page explains how that record works. Renders are transient by default; leave archiving off and we return the PDF and store nothing.

Render your markdown to HTML, then POST the HTML. The API prints it in a real browser.

curl https://api.sitepdf.com/v1/render \
  -H "Authorization: Bearer $SITEPDF_KEY" \
  -F html="<link rel='stylesheet' href='https://yoursite.com/pdf.css'><article>...your markdown rendered to HTML...</article>" \
  -F format=Letter \
  -F archive=true

{
  "pdf_url": "https://api.sitepdf.com/v1/documents/doc_md47c.pdf",
  "pages": 3,
  "rendered_in_ms": 1490,
  "archive": {
    "id": "arc_md91k",
    "captured_at": "2026-07-19T20:52:10Z",
    "retrieve_url": "https://api.sitepdf.com/v1/archives/arc_md91k"
  }
}

The API is in early access; this is the documented call shape it opens with. Full request and response walkthrough.

§ 05

Questions about this job

How do I convert markdown to PDF with an API?

Render the markdown to HTML with a markdown library (marked or markdown-it in Node, python-markdown in Python, or pandoc -t html), wrap it in an HTML shell with your CSS, then POST that HTML to a rendering API. The API prints it in managed Chromium and returns a searchable PDF, so no LaTeX and no local headless browser are involved.

Can I send raw markdown to the API instead of HTML?

Convert the markdown to HTML first in your own code, then send the HTML. This keeps you in control of exactly which markdown flavor, extensions and syntax highlighting you use, and it lets you attach your own CSS so the PDF matches your brand. Rendering markdown to HTML is one line with marked, markdown-it or python-markdown.

Is Pandoc or a rendering API better for markdown to PDF?

Pandoc with a LaTeX engine gives the best typography for books and papers and is free, but it needs a large install and ignores CSS. A rendering API is better when you want the PDF to match a web design, keep full CSS control, generate documents on demand, and avoid running LaTeX or a browser in your own server.

Why does my markdown to PDF output ignore my CSS?

Most likely the CSS is not attached to the HTML you converted. A markdown library returns only the body markup, so you have to inline your styles or link your stylesheet in the HTML before it is printed. A LaTeX-based converter ignores CSS entirely by design, which is why teams who want CSS control render the HTML in a browser instead.

How do I keep code blocks and tables looking right in the PDF?

Run your syntax highlighter over the HTML before printing so code blocks carry the right classes, and include the matching CSS in the document. Because a browser does the final layout, tables, monospaced fonts and highlighted code render exactly as they do on your site, which is the main reason the HTML plus browser path beats a LaTeX pipeline for web-styled documents.

§ Index

More PDF and archiving tools

§ Early access

Get on the early-access list

The API opens to the list first, in order. Early access locks the planned launch rates for 12 months. No card required, launching soon.