@react-pdf/renderer

Was ist es?

@react-pdf/renderer rendert React-Komponenten zu PDFs — server-side (Node) oder client-side. Statt HTML-zu-PDF-Hack (Puppeteer) wird ein eigener Renderer benutzt, der direkt PDF-Primitives ausgibt.

Quickstart

pnpm add @react-pdf/renderer

import { Document, Page, Text, View, StyleSheet, pdf } from '@react-pdf/renderer'

const styles = StyleSheet.create({
  page: { padding: 40 },
  title: { fontSize: 24, fontWeight: 'bold' }
})

const MyDoc = () => (
  <Document>
    <Page size="A4" style={styles.page}>
      <Text style={styles.title}>Bewerbung</Text>
    </Page>
  </Document>
)

const blob = await pdf(<MyDoc />).toBlob()

Typische Patterns

• StyleSheet.create statt inline — bessere Perf, Flexbox-Subset.
• <Font.register> für Custom-Fonts (TTF/OTF mit Unicode-Range).
• Server-side Render in Route Handler:

  // app/api/cv/route.ts
  const stream = await renderToStream(<MyDoc />)
  return new Response(stream as any, { headers: { 'Content-Type': 'application/pdf' } })
  

• Dynamische Daten ganz normal als Props rein.
• Mehrseitige Layouts via wrap und break-Props.

Gotchas / Was oft schiefgeht

• Keine HTML/CSS-Parität — nur Subset von Flexbox, keine grid, keine Pseudo-Klassen, kein position: sticky.
• Custom Fonts ohne Font.register → fallback auf Helvetica, oft fehlende Unicode-Glyphen (Umlaute!).
• Images: lokale Pfade in Node funktionieren, im Browser braucht's Data-URLs oder Fetch.
• Page break ist eigenwillig — wrap={false} auf Container nutzen, wenn nicht trennen.
• SSR mit Streaming + Next.js: korrekte Headers + Response-Body-Type beachten, sonst korruptes PDF.

Wann nicht?

Wenn du bestehendes HTML/CSS als PDF brauchst → Puppeteer / Playwright (Headless-Chrome). Für reine Daten-Tabellen → pdfkit direkt, weniger Overhead.