> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blinkpdf.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Markdown Rendering — How Blink PDF Converts Docs
> Blink PDF converts full CommonMark Markdown to professional PDFs without HTML, CSS, or LaTeX. Learn how the pipeline works.
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](https://commonmark.org/) specification. Every element you'd expect from a modern Markdown editor is supported out of the box:
| Element | Syntax example |
| ---------------- | ------------------------------------- |
| Headings | `# H1` through `###### H6` |
| Bold | `**bold**` |
| Italic | `*italic*` |
| Strikethrough | `~~deleted~~` |
| Highlight | `==highlighted==` |
| Subscript | `H~2~O` |
| Superscript | `E=mc^2^` |
| Unordered lists | `- item` |
| Ordered lists | `1. item` |
| Tables | GFM pipe tables |
| Links | `[label](https://example.com)` |
| Images | `` |
| Code blocks | Fenced ` ``` ` with language tag |
| Inline code | `` `code` `` |
| Blockquotes | `> quote` |
| Horizontal rules | `---` |
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](#images-remote-inline-and-staged) and reference them by handle. To make repeat renders of the same request deterministic and skip re-fetching within 24 hours, set [`pinRemoteImages: true`](/configuration/document-options#the-pinremoteimages-field).
## Images: remote, inline, and staged
Image sources are standard Markdown — Blink PDF supports three forms:
| Form | Syntax | Notes |
| ---------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Inline** | `` | Embedded in the request body; counts toward your input-size limit |
| **Remote** | `` | Fetched server-side under strict security (private-IP rejection, no mixed content) |
| **Staged asset** | `` | A reusable image uploaded out of band; fetched at render time and **not** counted toward the input-size limit |
A **staged asset** is uploaded once through the MCP [`upload_image`](/mcp/overview#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 `` 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](/guides/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](/configuration/document-options#the-imagesequence-field).
## 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](/configuration/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:
````markdown theme={null}
# Invoice #1042
**Date:** 2025-06-01
**Due:** 2025-06-30
| Description | Amount |
|--------------------|---------|
| API Platform (mo.) | $49.00 |
| Overage (2k reqs) | $4.00 |
| **Total** | **$53.00** |
> Payment terms: net 30. Thank you for your business.
```
Reference: INV-1042
```
````
```http theme={null}
POST https://api.blinkpdf.io/v1/render
Accept: application/pdf
Content-Type: application/json
x-api-key: bp_xxxxxxxxxxxxxxxxxxxx
```
```json theme={null}
{
"markdown": "# Invoice #1042\n\n**Date:** 2025-06-01 \n**Due:** 2025-06-30\n\n| Description | Amount |\n|---|---|\n| API Platform (mo.) | $49.00 |\n| Overage (2k reqs) | $4.00 |\n| **Total** | **$53.00** |\n\n> Payment terms: net 30. Thank you for your business.",
"metadata": {
"title": "Invoice #1042",
"author": "Acme Corp"
}
}
```
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:
| | Blink PDF | Chromium-based |
| ------------------ | ---------------------- | ----------------------------- |
| Browser startup | None | Required before rendering |
| Startup model | API process | Browser process |
| Runtime profile | Lightweight API render | Browser process and page load |
| Input format | Markdown | HTML + CSS |
| Layout determinism | ✅ | ⚠️ browser-dependent |
Large documents still avoid browser startup overhead because the engine processes the document tree in memory without spawning a browser context.
Learn how Blink PDF processes your Markdown in memory and never stores it.
Every PDF is PDF/UA-1 compliant with full Unicode and emoji support.