diegomura/react-pdf: generating PDFs with React components

The problem react-pdf solves, and who hits it

Most PDF tooling makes you describe a document twice: once in your application's component tree and again in a separate layout language. react-pdf removes that second description. The README states the package is a "React renderer for creating PDF files on the browser and server", so the document is a React component tree and the output is a PDF file. The audience is frontend and full-stack engineers who already know JSX and want invoices, reports or tickets produced from the same data that feeds their UI. The repository's package manifest is a Yarn workspace root named @react-pdf/root with packages/* and apps/examples, which tells you the renderer is one package among several rather than a single-file library. The README also draws a boundary immediately: if you want to display existing PDFs, it points to wojtekmaj/react-pdf, a different project. Confusing the two is the most common way to end up in the wrong repository.

How the renderer turns Document and Page into a file

The mechanism is a component vocabulary, not an HTML-to-PDF conversion. You import Document, Page, Text, View and StyleSheet from @react-pdf/renderer, and StyleSheet.create returns style objects that the renderer understands. The README's example sets flexDirection: 'row' on the page style, which is the tell: layout is flexbox, not the CSS box model you get in a browser. A Page has a size such as "A4", and Views nest inside it. From there the renderer walks that tree and emits PDF drawing operations. Two output paths exist in the README. On the web, PDFViewer renders the document into the DOM. On the server, ReactPDF.render takes the document and a file path. The repository layout reinforces the split: there are separate packages under packages/ and an examples app under apps/examples, and the root scripts include a dev command that runs @react-pdf/examples. The release list shows the surface is still moving, with @react-pdf/ui, @react-pdf/types and @react-pdf/tailwind all published on 2026-08-27.

Installing @react-pdf/renderer and rendering a first document

The README gives one install command, run from your project root. It adds the renderer package; React is assumed to be present already because you write the document as React components.

yarn add @react-pdf/renderer

With the package installed, the README's "How it works" example is the shortest complete document: a StyleSheet with a page style, a Document, and a Page sized "A4" holding two Views. Copy it as-is and you get a two-section A4 page when it renders.

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

const styles = StyleSheet.create({
  page: { flexDirection: 'row', backgroundColor: '#E4E4E4' },
  section: { margin: 10, padding: 10, flexGrow: 1 },
});

const MyDocument = () => (
  <Document>
    <Page size="A4" style={styles.page}>
      <View style={styles.section}><Text>Section #1</Text></View>
    </Page>
  </Document>
);

The Node path writes a file, the web path mounts a viewer

The README shows two consumers of the same document component, and picking the wrong one is a common first mistake. For a server-side job, import the default export and call render with an output path. The README's example uses a template literal for the filename, and the file appears at that path when the call completes.

import React from 'react';
import ReactPDF from '@react-pdf/renderer';

ReactPDF.render(<MyDocument />, `${__dirname}/example.pdf`);

For the browser, the README wraps the same component in PDFViewer and mounts it with ReactDOM.render into a DOM element.

import React from 'react';
import ReactDOM from 'react-dom';
import { PDFViewer } from '@react-pdf/renderer';

const App = () => (
  <PDFViewer>
    <MyDocument />
  </PDFViewer>
);

ReactDOM.render(<App />, document.getElementById('root'));

Where react-pdf is the wrong tool

The README's first section is titled "Lost?" and exists because people arrive here wanting to view PDFs. This package creates them. If your requirement is a scrollable viewer with page navigation, search or annotation on files you did not generate, react-pdf is the wrong dependency and the README says so directly. There is a second limitation worth stating plainly: the README documents no rollback, migration or version-pinning guidance for the renderer, so a team upgrading across a major release has only the changesets directory and the published packages to work from. The release list shows @react-pdf/ui at 1.0.0 while @react-pdf/types sits at 2.14.0, meaning the packages under this repository do not share a version line. Treat each package as its own upgrade decision. Finally, nothing in the README describes how the renderer behaves with content it cannot lay out, such as a table that overflows a page; the README does not document pagination rules, so verify that against your own document shapes rather than assuming.

react-pdf vs pdf.js and the viewer ecosystem

The searches around this project mix two different jobs, and the difference in approach is architectural. pdf.js is a parser and renderer for PDFs that already exist: it reads the file format and paints pages. react-pdf starts from the other end, with a component tree that has no PDF yet, and produces one. That is why the README redirects viewers to wojtekmaj/react-pdf, which is built on the pdf.js lineage. If your input is a PDF and your output is pixels on a screen, you want the pdf.js side. If your input is application data and your output is a downloadable file, you want this package. The related searches also surface react-pdf-highlighter and React-pdf-viewer/core, both of which belong to the viewing and annotation side of that line. Choosing between them is not a matter of quality; it is a matter of which direction the data flows.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-11, so it is current rather than abandoned. The licence is MIT, declared both in the README and in the root package.json, which permits commercial use and modification; that is a statement about the licence text, not legal advice for your situation. The upgrade cost is the interesting part. The root manifest uses Lerna with Changesets, so releases are cut per package and the changelogs are generated from pull requests. The three packages published on 2026-08-27 carry three different versions, and the workspace splits code across packages/. A consumer who installs only @react-pdf/renderer still inherits whatever the renderer depends on, so a version bump can arrive without you changing your own package.json. The README documents no deprecation policy and no support window, so pinning is the only lever the documentation gives you.

Editorial conclusion

Adopt @react-pdf/renderer when your team already writes React and the PDF is generated from data you control, and check the README example against your bundler before committing. Do not adopt it to display existing PDFs; the README points that use case at wojtekmaj/react-pdf instead. Before you build on it, verify how the package renders in your target runtime, since the README shows both a browser PDFViewer and a Node render call and does not document which one your deployment needs.

Frequently asked questions

Official sources

1. diegomura/react-pdf on GitHub
2. License: MIT
3. Project website
4. README
5. Releases