Skip to main content
Blink PDF takes standard Markdown as input and produces a polished, print-ready PDF as output — no templating language, no HTML wrangling, no CSS stylesheets. You write the content; the engine handles the layout.

​
Supported Markdown syntax

Blink PDF implements the full CommonMark specification. Every element you’d expect from a modern Markdown editor is supported out of the box:
Single tildes mark subscript (~sub~); double tildes remain strikethrough (~~delete~~). Unpaired ~ or ^ stay literal text.
Remote images are fetched at render time, which adds network latency to the render path. For the fastest renders, use base64-encoded data: URIs, host images on a low-latency CDN, or stage them once as assets and reference them by handle. To make repeat renders of the same request deterministic and skip re-fetching within 24 hours, set pinRemoteImages: true.

​
Images: remote, inline, and staged

Image sources are standard Markdown — Blink PDF supports three forms: A staged asset is uploaded once through the MCP upload_image tool: send the image bytes — a small image in a single call, a larger one as ordered parts — and get the handle back directly (no presigned URL, no PUT). The handle <sha256> is the SHA-256 of the bytes — hashed server-side — scoped per credential, and resolves in any POST /v1/render call made with the same API key. See Batch Processing for the full flow.
To lay out a set of staged images as pages — one image per page or a contact-sheet grid — use the imageSequence field instead of hand-writing Markdown. See Document Options.

​
Why you don’t need HTML, CSS, or LaTeX

Traditional PDF generation pipelines require you to write an HTML template, style it with CSS, and then pass it through a headless browser — all before the PDF even starts rendering. LaTeX-based tools add a compile step with its own syntax and error surface. Blink PDF removes all of that. The rendering engine understands Markdown semantics directly, so headings become bookmarks, bold text stays bold, and tables are typeset consistently — without a single line of CSS.
If you’re migrating from an HTML-to-PDF pipeline, you can often replace your entire template with a Markdown string that’s a fraction of the size.

​
How the rendering pipeline works

The pipeline is deliberately simple and deterministic:
  1. You send a POST /v1/render request with a markdown field in the JSON body.
  2. The engine parses your Markdown into a structured document tree.
  3. A theme is resolved (default report-clean) into a design bundle, then merged under any typography, page, furniture, or rules you set — your values win per field. See Themes.
  4. Layout and typesetting are applied — fonts are subset, Unicode is mapped, accessibility tags are injected.
  5. A PDF binary is streamed back in the response.
The same request always produces the same PDF output. There are no random seeds, no browser quirks, and no render-pass variability.

​
Example request

Here is a minimal Markdown document and the JSON body you’d send to render it:
The response is an application/pdf binary you can stream directly to your user or save to object storage.

​
Tables and code blocks

Tables are fully supported using the GitHub Flavored Markdown (GFM) pipe syntax. Column alignment (:---, :---:, ---:) is respected in the rendered PDF. Blink PDF does not impose row or column limits. Very wide tables may compact, split across pages, or overflow the content band while keeping hard min-content column floors — residual overflow is reported as a table-layout:overflow diagnostic with X-Render-Rendered-As-Requested: false rather than silently shrinking columns below readable widths. Code blocks are rendered in a monospace typeface with syntax-aware styling. Adding a language identifier after the opening fence (e.g., ```python) enables language labeling in the output — useful for technical documentation and runbooks.

​
The custom engine vs. Chromium

Many PDF services spin up a headless Chromium instance, load a webpage, and screenshot it to PDF. That approach has real costs: cold start times measured in seconds, high memory usage per render, and layout behavior tied to browser internals you don’t control. Blink PDF’s engine renders Markdown natively, without a browser:
Large documents still avoid browser startup overhead because the engine processes the document tree in memory without spawning a browser context.

Zero Retention

Learn how Blink PDF processes your Markdown in memory and never stores it.

Accessibility

Every PDF is PDF/UA-1 compliant with full Unicode and emoji support.