Obsidian to PDF: getting a book out of your vault

Obsidian is an excellent place to write a book and a poor place to produce one, and the gap between those two things catches people at exactly the wrong moment: the writing is done, and the file they get out looks nothing like what they had in mind.

The reason is worth understanding before you go looking for a plugin, because it tells you which of the three routes below is yours.

Why the built-in export looks like your app

Obsidian is an Electron application, which means the note you are looking at is a web page. Export to PDF asks that web page to print itself. Whatever your theme, your CSS snippets and your appearance settings are doing to the note on screen is therefore what lands in the PDF — your reading width, your heading colours, your code block styling, your accent colour on links.

That is not a bug. It is the honest consequence of printing a browser view, and it is the same reason printing from a Markdown preview produces a document rather than a book. A book has margins sized for a page, running page numbers, chapters that start on a fresh sheet, and one typeface chosen deliberately. A theme has none of those, because none of them mean anything on a screen.

The vault-specific syntax that does not survive

Obsidian's Markdown has extensions that only mean something inside Obsidian. In the vault they are conveniences; in an exported file they are the four things people write in to support forums.

• `[[Wikilinks]]` point at notes, and a note is not a page in a book. In the best case they print as plain text with brackets; in the worst they become dead links to a file nobody reading the PDF has.
• `![[Embeds]]` pull one note into another. Whether the embedded content is actually in the export depends on the route you take — and finding out after you send the file is the bad way to find out.
• Callouts (> [!note]) are Obsidian's own syntax on top of blockquotes. Anything that does not know about them renders the marker as literal text at the top of the quote.
• Plugin-generated content — Dataview queries, Templater output, task rollups — is computed while you look at it. What a converter sees in the file is the query, not the table it drew.

YAML frontmatter is the fifth one, and the easiest to forget. It is invisible in reading view, so people are surprised to see their tags and aliases printed at the top of page one.

Route 1: stay in Obsidian and fix the print CSS

If you want one note out and you want it now, the built-in export plus a print stylesheet is the shortest path. Obsidian applies CSS snippets to the print view, so a snippet scoped to @media print can undo the worst of the theme:

@media print {
  body { --font-text-size: 11pt; }
  h1, h2 { break-after: avoid; }
  h1 { break-before: page; }
  pre, blockquote, table { break-inside: avoid; }
}

That gets you chapters starting on a new page and headings that do not strand themselves at the foot of one. What it cannot give you is a page number in the footer or a table header that repeats across a break, because the print view has no concept of either.

Community plugins in this space — the various "better export" ones — mostly automate this layer: page size, margins, and sometimes headers and footers. They are a real improvement on the built-in command and still fundamentally a nicer browser print.

Route 2: Pandoc, if the toolchain is worth it to you

For a manuscript rather than a note, Pandoc is the serious answer, and there is an Obsidian plugin that shells out to it. You still have to clean the vault syntax first — Pandoc has no idea what a wikilink is — but once the file is portable Markdown you get real typesetting.

# Concatenate chapters in order, then typeset
pandoc chapters/*.md -o book.pdf --pdf-engine=xelatex \
  --toc --top-level-division=chapter

The cost is a LaTeX installation and a template you will end up editing. What Pandoc is superb at and where it stops covers that trade honestly; the short version is that it rewards people who like configuring things and punishes people who do not.

Route 3: export the text and design it elsewhere

The third route is to stop trying to make the vault produce the artefact. Obsidian holds plain Markdown files on your disk, which is the entire reason to use it — so the manuscript can leave without being converted, and the production step can happen somewhere built for pages.

Whichever tool you use for that step, the preparation is the same:

1. Strip the frontmatter from any note that is going into the book.
2. Resolve wikilinks. A link to another chapter becomes a cross-reference in words ("see chapter four"); a link to a note that is not in the book becomes plain text or goes away.
3. Flatten embeds. Paste the embedded content in, or drop it. There is no third option once the file leaves the vault.
4. Replace callouts with a blockquote, a heading, or a plain paragraph — whichever the content actually was.
5. Freeze plugin output. Copy the rendered table out of reading view and paste it back as a real Markdown table.
6. Fix image paths. Obsidian resolves attachments by vault-relative rules that nothing outside the vault shares.

Then combine the chapters in order into one file. A folder of notes is a vault's organising principle, not a book's, and every downstream tool wants the manuscript as a single document.

# Chapters named 01-..., 02-... concatenate in the right order
cat chapters/*.md > manuscript.md

That file is what you design. bukpress takes it from there — typefaces, margins, paper and covers set once, a hard page break on a line of `---`, page numbers in the footer, and the same file exporting both a PDF and an EPUB. The vault stays the place you write, which is what it is good at.

Which route is yours

The last row is the one that decides it for most people. Obsidian prints pages; it does not produce the reflowable file every ebook store asks for. If the book has a life beyond a PDF, the production step was always going to happen outside the vault — and knowing that early saves you a fortnight of fighting a print stylesheet.

The sample book is eight pages of what the other end of this looks like: one Markdown file, exported once, untouched afterwards.