What react-pdf Can Render Beyond Text

Updated

react-pdf renders more than plain strings: custom fonts, raster images, SVG graphics, interactive form fields, plus typographic controls like hyphenation and page breaks. The official site lists these under "Beyond text" and confirms the same document renders to a file, a stream, or a blob in Node or the browser. If your PDF needs branded type, charts, logos, or fillable fields, those are supported — but each has its own setup and constraints, covered below.

Custom fonts

You register a font source, then reference it by family name in styles. This is what lets you match a brand typeface instead of relying on built-in PDF fonts.

import { Font } from '@react-pdf/renderer';

Font.register({
  family: 'Inter',
  src: '/fonts/Inter-Regular.ttf',
});

// then in a style
const styles = { body: { fontFamily: 'Inter' } };

Expected result: text in the rendered document uses Inter. Common snags: the src must resolve at render time on whichever side you run (browser path vs. server file path), and you typically need a separate registration per weight/style rather than one file covering everything.

Images

Images render as document content, so they participate in the same flexbox layout as text. You point at a source and size it with styles. The practical constraint is availability: a remote URL must be reachable when the document renders, and on the server that means network access at render time. Local/asset paths behave differently between browser and Node, so test on the target side.

SVG graphics

SVG is supported, which is the usual route for logos, icons, and vector charts that must stay sharp at any zoom. Because it is vector, it scales without the pixelation you get from a raster image. If your SVG relies on external CSS or web fonts, expect to inline those dependencies — the renderer does not have a browser's full CSS cascade.

Form fields

Form fields are supported, meaning the output can include fillable inputs rather than being a flat, print-only document. This matters for workflows where a recipient completes the PDF after you generate it. Decide early whether you need an interactive form or a fixed layout, because that choice affects how you structure the document.

Hyphenation and page-break control

Two text-layout controls are called out explicitly:

  • Hyphenation — breaks long words at line ends so justified or narrow columns don't develop large gaps.
  • Page-break control — lets you decide where content splits across pages, so headings don't strand at the bottom of a page or tables don't split mid-row.

These are the features that separate a document that merely contains the right content from one that reads cleanly when printed.

How this fits the rendering model

All of the above render through the same pipeline: one document definition, output as a file, a stream, or a blob, in Node or in the client. Layout uses Yoga, which brings flexbox to the page — rows, columns, wrapping, and absolute positioning. So the mental model is: you lay out with flexbox you already know, and the "beyond text" features are just additional node types inside that layout.

Choosing whether this covers your case

Need Covered? Watch for
Brand typeface Yes, custom fonts One registration per weight; correct src per environment
Logos, icons, charts Yes, images and SVG Remote sources must be reachable at render time; inline SVG dependencies
Fillable documents Yes, form fields Decide interactive vs. fixed layout up front
Clean multi-page text Yes, hyphenation and page breaks Configure breaks deliberately; don't rely on defaults

If your requirement is outside this list — for example, heavy print-production features like CMYK color management or PDF/X compliance — the site's feature summary does not claim them, so verify against the docs before committing. For most product documents (invoices, reports, certificates, branded exports), the listed capabilities are the ones you'll actually use.