# Export

> Export one document or a whole project as Markdown, self-contained HTML, or PDF — where the buttons are, what each format keeps, and what it drops.

Every export is a plain `GET` request, and every export button is an ordinary link. Anything you can
click, you can also bookmark, script, or fetch with `curl`.

## Where the buttons are

Open a document in the reading view of either the DocuCommit editor (desktop app) or the DocuCommit
server (read-only web app). The **Actions** panel beside the page carries three links:

- **Export Markdown**
- **Export HTML**
- **Export PDF**

On the server that panel also holds **History** and a follow button; in the editor it also holds
**Delete**, **Edit**, **History**, and **Move**. A project's own page has the same three export
links in its Actions panel, and there they export the whole project.

## The URLs

```
GET /projects/{project}/export/{section}/{document}?format=md
GET /projects/{project}/export?format=pdf
```

`format` accepts `md` (or `markdown`), `html`, or `pdf`; anything else returns `400`. The response
comes back as an attachment named after the document or project slug, with the matching extension.
On a server holding more than one library, the same two paths also exist under `/library/{library}/`.

## The three formats

| Format | `format` value | What you get |
| --- | --- | --- |
| Markdown | `md`, `markdown` | The source file, byte for byte, frontmatter included |
| HTML | `html` | One self-contained `.html` file — no external stylesheet, no external images |
| PDF | `pdf` | The same page rendered through a compact print stylesheet |

**Markdown** reads the file off disk and changes nothing about it.

**HTML** renders the page through the same flexmark pipeline the editor and the server use, then
makes the result stand alone: the stylesheet is inlined into a `<style>` block instead of linked,
and images stored in the project's `_attachments/` folder are embedded as base64 data URIs. PNG,
JPEG, GIF, SVG, and WebP are recognised and carry their proper media type.

**PDF** builds that same HTML with a print stylesheet in place of the site's — sans-serif, 11pt,
1.5 cm margins, wrapping code blocks — and converts it. Callouts keep their colours and their
*Information* / *Success* / *Warning* / *Danger* labels.

Rendered exports keep the reading layout around the page — breadcrumbs, the project tree, the
on-page contents list — with the action links removed.

## Whole-project exports

A project export walks the project in tree order, top to bottom.

- **Markdown** joins the raw source files with a `---` horizontal rule between them.
- **HTML and PDF** insert a heading in front of each section as the walk enters it — `<h2>` for a
  top-level section, one level deeper for each level of nesting — and separate documents with a
  horizontal rule.

## What survives, and what does not

**Includes are expanded in HTML and PDF.** The export renderer resolves `include` fences, so a
transcluded document appears inline in the exported file. The Markdown export copies the file from
disk, so it keeps the fence exactly as you wrote it.

**Mermaid diagrams and code highlighting do not survive.** Both are done by the browser at display
time, so HTML and PDF exports contain the fenced source in a plain code block instead of a diagram
or coloured code. draw.io diagrams are the exception: they are stored as SVG files and come through
intact.

**Only images are bundled.** An attachment that is linked rather than shown — a PDF, a spreadsheet,
a zip — stays a link in the HTML export, pointing back at the DocuCommit URL it came from. The same
applies to the navigation and to links between documents: those are root-relative URLs that need a
running DocuCommit to resolve.

**There is no DOCX export.** Markdown, HTML, and PDF are the three formats. Comments made on the
server are not part of any of them.

For what the Markdown itself may contain, see the
[Markdown reference](/docs/writing/markdown-reference/).
