# pdfme: JSON templates, nine workspace packages, three CLI verbs

> pdfme is a TypeScript and React monorepo for generating PDFs from JSON templates on Node and in the browser. Its front page is short, so font, schema and CLI decisions sit in linked docs and in the @pdfme/cli package.

**pdfme/pdfme** — Open-source PDF generation library built with TypeScript and React. Features a WYSIWYG template designer, PDF viewer, and powerful generation capabilities. Create custom PDFs effortlessly in both browser and Node.js environments.

- Repository: https://github.com/pdfme/pdfme
- Website: http://pdfme.com/
- Stars: 4,857 · Forks: 524
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/pdfme-pdfme

## Nine workspace packages and a staged build order

pdfme is an npm workspace monorepo, and package.json names nine members: packages/common, packages/pdf-lib, packages/jsx, packages/converter, packages/schemas, packages/generator, packages/manipulator, packages/ui and packages/cli. That manifest fragment is the quickest way to see the split of responsibilities:

```bash
packages/common
packages/pdf-lib
packages/jsx
packages/converter
packages/schemas
packages/generator
packages/manipulator
packages/ui
packages/cli
```

The build is not a flat loop over those nine. It cleans, builds pdf-lib, common, converter, schemas and jsx one at a time, runs generator, ui and manipulator together, then builds the cli last:

```bash
npm run build -w packages/pdf-lib && npm run build -w packages/common && npm run build -w packages/converter
./scripts/build-workspaces-in-parallel.sh packages/generator packages/ui packages/manipulator && npm run build -w packages/cli
```

Two details cost adopters time. The clean step is not plain npm: it runs `vp run --filter '@pdfme/*' clean`, so that tool has to be installed before a full build works. And there is a narrower path when you only need generation, plus one command that gates formatting, lint, types and tests:

```bash
npm run build:cli
npm run fmt:check && npm run lint && npm run typecheck && npm run test && npm --prefix playground run test
```

Order matters more here than in a typical library. Because schemas and common compile before generator and ui, a change to a shared type surfaces as a build failure in three downstream packages rather than as a type error in one.

## The CLI gives you three verbs and nothing more

For agentic workflows, local verification or JSON first template iteration, the project points at `@pdfme/cli`, documented in packages/cli/README.md. The front page names exactly three subcommands, and each has one job:

```bash
pdfme validate
pdfme doctor
pdfme generate --image --grid
```

`pdfme validate` checks a template or a unified job JSON before generation. `pdfme doctor` diagnoses runtime, font, `basePdf` and output path issues before `generate` runs. `pdfme generate --image --grid` produces the PDF and rendered page images so you can inspect layout without opening a viewer. What the page does not give you is the ring around those verbs: no flags for validate or doctor, no sample input file, no exit codes and no error text. A pipeline that wants to gate on validation has to read packages/cli/README.md first, and a CI step should not assume a non zero exit is the failure contract until that file says what it is. The same page names DeepWiki as the place to ask questions about docs and source, which is the intended fallback when the CLI write up is thin.

## Templates are JSON data, so the designer is optional

The feature table makes three claims, and the third is the one that shapes your integration. Generation is fast because templates remove the need for complex operations, and the same code runs on Node and in the browser. Anyone can build a template in the WYSIWYG designer. Templates themselves are JSON data. Read together, the designer is one way to produce that file, not a requirement. A team can skip it, commit templates to version control, diff them like any other data file and generate in Node with no browser in the picture. The cost lands on the schema. The repository only tells you that schemas live in packages/schemas, and it prints no field names, no required keys and no validation messages, so a hand written template has to be checked against that package or handed to `pdfme validate` before it reaches production. The table also leaves scope open, pointing at a Supported Features page instead of enumerating what a template may contain.

## The README ships no install command and no code sample

There is no install command on the repository front page. No npm install line, no TypeScript snippet, no sample output PDF, no pinned version. What you get instead is a set of exits: a Getting Started guide at pdfme.com/docs/getting-started, a Supported Features page at pdfme.com/docs/supported-features, the pdfme-playground site plus its source under the playground directory, DEVELOPMENT.md for setup, DeepWiki for interactive questions, and a Discord server. The badges do link the published packages, naming @pdfme/generator and comparing @pdfme/common, so the package names are discoverable even though the install line is not written down. For an engineer choosing between libraries, the consequence is concrete: the front page cannot answer the questions that decide it. Minimum Node version, template fields, font handling and CLI exit codes all live somewhere else, so budget time for the docs and the playground before you commit a sprint. The repository does keep a Node version in .nvmrc and pins its own tooling through .npmrc, .oxfmtrc.json and .oxlintrc.json, files that serve contributors while consumers get no version policy in writing.

## doctor names fonts and basePdf as the failure points

What `pdfme doctor` inspects is a short list of the things that break a template driven pipeline: the runtime, fonts, `basePdf` and the output path, all checked before generate runs. That ordering matters, because it tells you where a blank or shifted page comes from. The engine itself is borrowed. pdf-lib performs PDF generation, fontkit handles font rendering and PDF.js handles viewing, so pdfme is a schema and layout layer on top of three libraries rather than a PDF engine of its own. For a reader, the practical consequence is that an unusual font is the real risk. Rendering goes through fontkit rather than the browser's own text engine, and the repository documents no font licensing checklist, so check the fonts your template embeds and the base PDF you start from before you ship. The tool that reports those two classes of problem is `pdfme doctor`, and it runs before generation, not after, so a layout question is worth asking there first.

## Paid feature work still ships as MIT code

pdfme takes paid feature requests. The README says the authors will evaluate and implement a requested feature for a fee, that any additional functionality will always be released as open source, and that the request goes through app.pdfme.com/contact. Treat that as a constraint rather than a bonus. There is no closed enterprise build, because a paid feature lands in this repository under the MIT license on the same release train as 6.2.1, 6.2.2 and 6.2.3. If your requirement has to stay confidential, this route cannot serve it and you need your own layer around the template schema. The same page points at a separate hosted service, pdfme Cloud, whose stated additions are generation at scale without infrastructure management, a hosted WYSIWYG designer, an API and automatic updates. That is the authors' own recommendation for people who would rather not run the library themselves, and taking it means template design and generation move to someone else's service while the open source library stays as it is.

## The designer inherits six upstream libraries

pdfme does not write its own editor. React, form-render and antd build the UI; react-moveable, react-selecto and @scena/react-guides handle the manipulation, selection and guide layers; dnd-kit handles drag and drop; Lucide supplies the icons, including the Schema icon. The drag and drop dependency is linked from github.com/clauderic/dnd-kit rather than from the kit's own repository, which matters when you audit what a designer install pulls in. The effect for an adopter is twofold. A designer bug can belong to an upstream package rather than to pdfme, which makes issue triage slower. And because the README pins nothing here, there is no compatibility matrix for React or for these UI packages, so the version ranges in your own lock file decide which editor behaviour you get. If the designer is core to your product, test it against your React version before building a workflow on top of it.

## Three patch releases in ten days and a draft migration guide

Activity is current. The repository is not archived, the last push was on 2026-10-05, and release 6.2.3 was published the same day, after 6.2.2 on 2026-09-30 and 6.2.1 on 2026-09-26. Three patch releases in ten days makes the version you develop against a real decision, and no deprecation window for template fields is documented, so pin what you build with. The surface is also still moving. The README sends you to a draft migration guide at website/docs/migration-v6.md for the planned next major release changes, and a draft is not a changelog: it does not say which fields will be renamed or when. Treat a schema you build now as something to migrate later. The contributor files at the top level, RELEASE.md, PLAN.md, DEVELOPMENT.md, AGENTS.md and CLAUDE.md, are where to look for the process behind those releases, and the sponsors table shows ProgressLab, PhotoQuest and Famly funding the work without any paid tier attached to the library itself.

## Conclusion

pdfme fits teams that already work in JSON data and want a designer, a generator and one runtime story on Node and in the browser, and who will read the linked docs before committing. It does not fit a team that needs the install command, the template field list and the CLI exit codes printed on the front page, and the paid feature route cannot hand you a closed build. Before adopting, read packages/cli/README.md to learn what validate, doctor and generate accept, run `pdfme doctor` against your own fonts and base PDF, and read the website/docs/migration-v6.md draft, since a major release is planned and template fields are not versioned in the README.

## FAQ

### What does PDF me do?

pdfme is a TypeScript PDF generator with a React based UI, published under the MIT license. It generates PDFs from JSON templates on Node and in the browser, and ships a WYSIWYG template designer plus a CLI with validate, doctor and generate.

### Which pdfme package should I install?

The badges link the published packages as @pdfme/generator and @pdfme/common, and the repository is an npm workspace monorepo with packages/common, packages/pdf-lib, packages/jsx, packages/converter, packages/schemas, packages/generator, packages/manipulator, packages/ui and packages/cli. The README itself contains no install command.

### What does pdfme doctor check?

It diagnoses runtime, font, basePdf and output path issues before generate runs. The same list names pdfme validate for checking a template or unified job JSON, and pdfme generate --image --grid for producing PDFs plus rendered page images to inspect layout.

### Is pdfme free, and do paid features stay closed?

The library is MIT licensed and the README states it will always remain open source. Paid feature requests are evaluated and implemented for a fee, and any additional functionality will always be released as open source. A separate hosted service, pdfme Cloud, is offered for people who prefer a managed setup.

## Sources

- [License: MIT](https://github.com/pdfme/pdfme/blob/main/LICENSE)
- [pdfme/pdfme on GitHub](https://github.com/pdfme/pdfme)
- [Project website](http://pdfme.com/)
- [README](https://github.com/pdfme/pdfme/blob/main/README.md)
- [Releases](https://github.com/pdfme/pdfme/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pdfme-pdfme