Home · Docs · Import + Export · Export as PDF

Export as PDF

PDF export uses the browser's print → Save as PDF pipeline. A clean stylesheet, optional brand colors, no app chrome in the output.

PDF export in sweetdocs goes through the browser’s print pipeline — we open a clean print-only tab with your doc rendered, then trigger the browser’s print dialog. From there you pick Save as PDF as the destination.

We chose this over a native PDF generator because every browser already ships a high-quality PDF renderer; bundling our own would add ~2 MB to the app for no fidelity gain.

Print

Kyoto, days 1-3

We land in Kyoto on the 12th and have three full days before Osaka. The bamboo grove at Arashiyama is best at dawn, Fushimi Inari takes a morning, and the Nishiki food markets are worth a slow afternoon.

  • Reserve the dawn slot at Arashiyama.
  • Pre-book the Nishiki food tour for Saturday.
const total = perDay * 3

The second page continues with Osaka logistics, ramen stops, and the return train.

How to export

Two paths, same result:

PathBehavior
Doc toolbar → download iconPDF (via Print)Opens the print tab
Doc toolbar → print iconSame — direct shortcut

The browser’s print dialog opens. Pick Save as PDF (Chrome, Edge, Brave, Arc) or Save PDF to Files (Safari) as the destination.

What’s in the printed page

The print tab is a stripped-down render of just your document:

The original tab stays where it was; the print tab self-closes after you finish (or cancel) the print dialog.

Brand colors

The print stylesheet has a per-device preference for brand colors:

SettingEffect
Brand colors on (default)Headings, links, and code blocks use sweetdocs’s accent palette
Brand colors offPure black-on-white printing — best for archival or for greyscale printing

Toggle this per device — it’s stored in localStorage (sweetdocs:print_brand_colors). The setting persists across sessions on the same browser.

To change the setting: …(toggle is in the print preview UI when implemented — for now, the default-on behavior covers most cases).

Paper size, orientation, margins

These are all controlled by the browser’s print dialog, not by sweetdocs:

This means whatever your browser supports for PDFs, sweetdocs’s PDF export supports too. Page numbers, header / footer text, page ranges — all there.

What survives in the PDF

ElementResult
HeadingsStyled as in the print stylesheet (size, line, weight)
Inline marksBold, italic, monospace — all visible
Lists, nested listsIndented as expected
TablesBordered Markdown tables, paginate naturally
Code blocksMonospaced, with subtle background; wrap to next page if needed
ImagesInline; respect the width and alignment from the doc
LinksUnderlined in brand color; clickable in the resulting PDF (most browsers preserve link annotations)
Hex color swatchesVisible inline alongside the literal hex

What doesn’t survive

ElementReason
Live cursors / collaborator avatarsNot rendered in print mode
CommentsNot rendered (comments live in their panel, not the body)
Sidebar, toolbar, app chromeStripped — the print tab is content-only
AnimationsNone to animate in print

Why “via Print”?

We label this PDF (via Print) in the menu because the dialog the user sees is the browser’s print dialog, not a save-as-PDF dialog. The labeling is intentional — it warns you that you’ll see a print UI and need to pick PDF as the destination yourself.

Once you’ve done it once on a given browser, the default destination stays as PDF and the rest is muscle memory.