EasyInvoicePDF: a self-hostable invoice generator that renders PDFs in the browser

What EasyInvoicePDF solves, and for whom

Most free invoice tools ask for an account before they will hand over a PDF. EasyInvoicePDF takes the opposite position: the README states there is no sign-up, no ads, and that generation happens in the browser with no server uploads. The repository description repeats the same claim, calling it 100% in-browser. For a freelancer who invoices a handful of clients a month, that removes the account, the email confirmation and the question of where the invoice data ends up.

The second audience is developers. The stack is TypeScript, Next.js, React, Tailwind and shadcn-ui, with react-pdf-renderer doing the document rendering. The README lists a Stripe-style template alongside a default one, and the repository carries a components.json and a tailwind.config.ts, which is the shadcn-ui setup. If you need an invoice layout inside your own product, that combination is a reasonable starting point rather than a blank page.

What it is not: an accounting system. Nothing in the README describes invoice history, recurring billing, payment reconciliation or client records beyond saved seller and buyer profiles. Treat it as a document generator.

How the PDF actually gets built

The release notes for v1.0.4 describe the rendering change directly: the invoice PDF is generated once and shared by the desktop preview, the mobile viewer and the download button. That is the core mechanism. Form state drives a single PDF document object, and every surface that displays or exports the invoice reads from that one object. Before this release the preview and the download could diverge, which is why the notes mention a flicker-free preview as the headline improvement.

The rendering itself runs through react-pdf-renderer, which is why the preview can update as you type instead of waiting on a server round trip. Layout concerns are handled in the same layer: the README describes multi-page support with automatic pagination and page breaks for large invoices, so a long line-item table splits across pages rather than overflowing.

Around that core sits a Next.js application. The repository layout shows a src/ directory, a messages/ directory for translations, and an e2e/ directory with a playwright.config.ts. The README claims 10+ languages and 120+ currencies, and the messages directory is where the first of those lives. There are also Sentry configuration files at the repository root, and the .env.example exposes SENTRY_ENABLED and NEXT_PUBLIC_SENTRY_ENABLED, both set to false by default.

Running EasyInvoicePDF locally

The repository is pinned to pnpm: there is a pnpm-lock.yaml and a pnpm-workspace.yaml, and package.json scripts call pnpm directly, including an update-deps script. The .env.example file opens with the instruction to copy it, so start there. Note that every variable in it is empty or set to a disabled flag, which means a plain local run does not require any third-party account.

cp .env.example .env.local
corepack enable
pnpm install
pnpm dev

The dev script is next dev, so the app comes up on port 3000. The expose-to-internet script in package.json is a cloudflared tunnel pointed at http://localhost:3000, which confirms the port.

For a first real use, open the app, fill in the seller and buyer blocks, add line items, and watch the preview pane. The README's v1.0.3 notes describe an email visibility toggle for seller and buyer, and a confirm dialog that warns about unsaved changes when you close those dialogs. Export produces the PDF through the same generated document the preview uses.

The environment file also documents a second, less obvious path: an API that generates and emails an invoice. That needs RESEND_API_KEY, UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN, an AUTH_TOKEN, plus SELLER_* and BUYER_* values and INVOICE_NET_PRICE. There are optional Telegram notification variables and Google Drive variables for uploading the result. None of this is needed for the browser-only flow.

pnpm type-check
pnpm lint
pnpm e2e

Those three scripts exist in package.json and are the checks to run before changing template code. The e2e suite uses Playwright and the repository has an e2e:update-snapshots script, so visual template changes will need snapshot updates.

The self-hosting path is underdocumented

This is the sharpest limitation. The README is written for people using the hosted site at easyinvoicepdf.com. It documents features, screenshots and release notes. It does not document deployment. There is no self-hosting section, no Dockerfile in the top-level repository listing, and no description of what a production build needs beyond the standard Next.js scripts.

That matters because .env.example implies more moving parts than the browser-only pitch suggests. Resend for email, Upstash Redis for what the file calls subscription tokens, an AUTH_TOKEN used for /api, and two Sentry flags. A reader who wants a purely local, single-user invoice generator has to work out which of those are optional. The file's own comments say the Resend and Upstash keys are for emails and subscription tokens respectively, which suggests the core browser flow does not need them, but nothing states that outright.

There is a second gap. The README does not document rollback, backup, or what happens to saved seller and buyer profiles. Since the privacy claim rests on browser-only operation, it is worth confirming where those profiles are stored in a deployed instance before you put real client data in.

A third, smaller issue: the README's feature list mixes the hosted product and the code. Shareable links and QR codes are described as features, but the repository gives no explanation of how a shared link is encoded or whether it embeds invoice data in the URL. If you plan to self-host and share links with clients, read the source before assuming the behaviour matches the hosted site.

EasyInvoicePDF against a document library like react-pdf

The honest alternative is not another invoice SaaS. It is react-pdf or react-pdf-renderer used directly, which is what EasyInvoicePDF already builds on. If your need is a PDF with a table and a total, a few hundred lines of React around that library will do it, and you keep full control of the layout.

The difference is scope. EasyInvoicePDF ships the parts that are tedious rather than hard: the seller and buyer forms with a locked-state banner, the tax label handling for VAT, GST and sales tax, the currency and language switching, the QR code block, the pagination for multi-page invoices, and the Stripe-style template. Writing those yourself is a week of layout work and a longer tail of edge cases around long item names and page breaks.

A dedicated accounting platform such as Invoice Ninja or a hosted invoicing service is the other direction. Those store invoices, track payment status and produce reports. EasyInvoicePDF does none of that. Choosing it means accepting that the PDF is the deliverable and the record-keeping is your problem.

The trade-off is licence. EasyInvoicePDF is AGPL-3.0, while react-pdf-renderer is MIT. If you embed AGPL code in a network service, the AGPL's source-availability terms reach the users of that service. Pulling react-pdf-renderer in directly avoids that entirely. This is a real consideration, not a formality, and it is the main reason a commercial team might take the library and skip the application.

Maintenance, releases and what AGPL-3.0 means here

The repository is not archived, and the last push was on 2026-09-10. Release cadence is visible in the tags: v1.0.2 in March 2026, v1.0.3 on 2026-03-29, and v1.0.4 on 2026-09-04. That is two substantive releases in roughly six months, with v1.0.4 bundling a rendering change, a mobile redesign and a Next 15 upgrade.

Upgrade cost is dominated by that framework version. A Next.js major upgrade is not a drop-in when the project also carries Playwright snapshot tests and Sentry configuration. The e2e:update-snapshots script exists precisely because template rendering changes break visual tests, so budget for re-baselining snapshots after any template or dependency work.

The tooling is opinionated and worth knowing before you fork. Linting runs through oxlint with type-aware rules, formatting through oxfmt, and unused-code detection through knip. There are Husky hooks and a lint-staged config, so a fork inherits those on install.

On licensing: package.json marks the project private, but the repository carries an AGPL-3.0 LICENSE file, and the README presents it as free and open source. The AGPL's defining feature is the network clause, which requires that users interacting with a modified version over a network be offered the corresponding source. I am not a lawyer and this is not legal advice. If you plan to modify EasyInvoicePDF and expose it to customers, get the licence reviewed before you build on it. If you only run it unmodified for your own invoicing, the practical exposure is much smaller.

Editorial conclusion

Adopt EasyInvoicePDF if you want a browser-based invoice generator you can run yourself, or if you need a React and react-pdf-renderer starting point for your own invoice template. Do not adopt it as a billing system: it stores no invoice history, issues no invoice numbers, and its AGPL-3.0 licence will not suit a closed-source product. Before you commit, verify three things in your own checkout: which environment variables your deployment actually needs, whether the /api routes you expose are meant to be public, and whether the template output matches the tax and layout rules your jurisdiction expects.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. VladSez/easy-invoice-pdf on GitHub