Skip to main content
There are two ways out of open-pdf: the Download button in the preview, and the open-pdf export CLI. Both render through the same Takumi engine that draws the preview, so what you export is what you saw.

​
The Download button

The preview toolbar has a Download button that saves the current document as a PDF. It is a clean render: no inspector metadata, no source-line mapping, none of the instrumentation that powers click-to-inspect. Just the document. Use it when a human is looking at the preview and wants the file now. Use the CLI when an agent or a script needs to produce files headlessly.

​
The export CLI

open-pdf export renders docs to files without starting a server. It spins up a middleware-mode Vite instance internally, so your TSX compiles through the exact same pipeline as the dev preview: same plugins, same aliases, same JSX transform.
Doc ids are the folder names under docs/, the same ids the preview uses. Passing an unknown id fails with the list of available docs. Each rendered file prints with its size and render time:
Flags:

​
Editable Word files

--format docx does not embed a PDF or rasterize pages. It serializes the document tree into real OOXML, so the result opens in Word as a document someone can keep editing:
  • Real paragraphs and headings. h1 through h3 map to Word’s Heading 1 to 3 styles with outline levels, so the document has a navigable structure pane. Deeper headings clamp to Heading 3.
  • Tables with repeating headers. <thead> rows carry Word’s repeat-on-every-page flag, so long tables stay labeled as the reader scrolls, the same behavior described in Tables.
  • Images. Embedded as native media at their rendered dimensions.
  • Live page-number fields. <PageNumber /> and <TotalPages /> become Word PAGE and NUMPAGES fields. When the reader edits and the document reflows, the numbers update.
  • Headers and footers. pageOptions.header and pageOptions.footer become Word running bands, including justified layouts like Page X of Y on the right.
  • Lists, bold, italic, underline, colors, alignment, page breaks. break-before-page becomes a Word page break, break-inside-avoid becomes keep-lines.
Page size and margins carry over from pageOptions for named sizes (a4, letter, legal, a3, a5).

​
The Google Docs path

Google Drive converts .docx files to Google Docs natively. This is the intended path for handing a document to someone who lives in Docs:
1

Export

npx open-pdf export proposal --format docx
2

Upload to Google Drive

Drag export/proposal.docx into Drive, or upload it via the Drive API.
3

Open with Google Docs

Drive converts on open. Headings, tables with repeating headers, images, and page-number fields survive the conversion. Verified.
The result is a real Google Doc the recipient edits and comments on, with no awareness that it started as JSX.

​
What does not carry over

DOCX export is faithful to structure and text. It approximates visual styling, because Word is a different layout engine, and that is the point of exporting to Word: the reader edits on.
  • Exact visual fidelity. Spacing, line breaks, and font rendering will differ from the PDF. If pixel-exact output matters, ship the PDF.
  • Inline <svg>. Skipped, with a warning. Rasterize to an image if a graphic must survive.
  • Custom pixel page sizes. size: { width, height } falls back to A4 in DOCX. Named sizes carry over.
Skipped content prints as warnings on stderr during export, per doc, so an agent can see exactly what was dropped:
The PDF output of open-pdf export is byte-identical in rendering to the preview. DOCX is a translation, not a render. Review the .docx once in Word or Google Docs before sending it somewhere important.

​
Next

CLI reference

All commands and flags, including dev, build, and sync:skills.

Pagination

Page sizes, margins, headers, footers, and break control.