EasyInvoicePDF: A Browser-Only Invoice Generator Built on react-pdf-renderer

The problem EasyInvoicePDF addresses: invoice PDFs without an account or a backend

Most invoice tools ask you to register before you can produce anything. EasyInvoicePDF takes the opposite position: the README states there is no sign-up required and the experience is ad-free, and the feature list describes a browser-only workflow with no server uploads. That combination is the product's whole pitch. It is aimed at freelancers, contractors and small operators who need a one-off or occasional invoice and do not want a subscription, an account, or their client list sitting on someone else's server. The repository topics include self-hosted, so the intended audience also includes people who want to run the generator on their own infrastructure rather than use the hosted instance at easyinvoicepdf.com. The scope is deliberately narrow: produce an invoice, preview it live, export a PDF, optionally share a link. There is no payment collection, no accounting ledger, no recurring billing. If your requirement is a billing system, this is not one.

How the PDF actually gets made: react-pdf-renderer in the client

The stack is TypeScript with Next.js, shadcn-ui and Tailwind CSS, and the PDF layer is react-pdf-renderer, which appears in the repository topics. That choice explains the live preview. The invoice form state and the PDF document are the same React tree, so typing in a field re-renders the document rather than round-tripping to a server. Release v1.0.4 is specifically about this path: the release notes say the invoice PDF is generated once and shared by the desktop preview, the mobile viewer and the download button. Before that change, the same document was presumably rendered more than once, which is what produced the flicker the release title refers to. The v1.0.4 notes also mention a fix for PDFs missing the first characters of labels, citing the Spanish string Cobrar de rendering as obrar de in rare cases. That is a text-measurement bug in the rendering layer, not a data bug, and it is the kind of failure you only see in the PDF output, never in the form. Multi-page invoices are handled with automatic pagination and page breaks according to the feature list, and QR codes can be embedded with payment links, UPI strings or custom data. The data flow is therefore form state to React document to PDF bytes, all inside the tab.

Running it yourself: the setup the README implies

The README does not include an installation section, which is a real gap for a project whose topics include self-hosted. What can be confirmed from the repository metadata is the shape of the project: TypeScript, Next.js, default branch main, and a homepage at easyinvoicepdf.com. A Next.js application of this kind is normally started with npm install followed by npm run dev for a local server and npm run build for a production bundle, but the README as supplied does not state those scripts, so treat the exact command names as unverified until you read package.json. The same applies to any environment variables. Because the stated design is browser-only with no server uploads, you should not expect a database URL or an API key in the setup, and if you find one, that is worth understanding before you deploy. The hosted instance exposes template selection through a query parameter, for example easyinvoicepdf.com/?template=stripe in the README's own link, which tells you templates are addressable from the URL. Whether that parameter works identically in a self-hosted build is not stated.

Where the browser-only model breaks down

Client-side rendering puts a hard ceiling on document size. Every invoice is laid out in the tab, and the release notes describe multi-page support as automatic pagination, which is a layout concern rather than a data concern. A few hundred line items will be slower to preview than a ten-line invoice, and the cost is paid on the user's device. The more interesting limitation is durability. The README advertises saving seller and buyer profiles for reuse, and v1.0.3 added a confirm dialog to discard changes, which implies unsaved work lives in the session and can be lost. Nothing in the supplied material describes a server-side store for those profiles or for invoices, so the persistence story is unclear. Then there are shareable links. The README lists sending invoices directly to clients without attachments as a feature. If the link encodes the invoice in the URL fragment, the data stays client-side and the privacy claim holds. If it posts to a backend, the no server uploads claim needs qualification. The material does not say which, and that ambiguity matters more than any template detail. Finally, AGPL-3.0 is a strong copyleft licence. If you modify EasyInvoicePDF and let users interact with it over a network, the licence's network clause is the thing your legal reviewer will want to read. That is not legal advice, just the clause that distinguishes AGPL from GPL.

Comparing it with a PDF library you wire up yourself

The obvious alternative is not another invoice app but a PDF library used directly, such as PDFKit or pdf-lib, or a hosted document API. The difference is where the invoice structure lives. EasyInvoicePDF ships the structure: seller and buyer blocks, line items, tax labels, currency and language selection, templates, pagination. With a raw PDF library you get drawing primitives and you write the layout, the tax arithmetic and the pagination yourself. That is more work and more control. It also means the invoice schema is yours, which matters if you need to import and export invoice data programmatically. EasyInvoicePDF's feature list describes VAT, GST, sales tax and custom tax labels with automatic calculations, and 10 or more languages with 120 or more currencies, but it does not describe a documented JSON schema for import or export. If your workflow is generate one invoice at a time through a UI, the shipped structure is a win. If your workflow is generate five hundred invoices from a database nightly, a library plus your own schema is the better fit, because the browser-only design is actively working against you there.

Templates, maintenance and what a fork costs you

The README highlights multiple fully customizable templates including a Stripe-style design, and the screenshot table shows a default template and a Stripe template side by side. Customizable here means the fields and branding are editable in the UI, not that you can drop in arbitrary layout code without touching the source. Logo support is listed, and tax labels are customizable, so most white-labeling needs are covered without a fork. Forking is where the AGPL-3.0 obligation and the maintenance cost meet. The release history shows v1.0.2 in March 2026, v1.0.3 later that same month, and v1.0.4 in September 2026, so the project is moving but not rapidly. Each release has touched real rendering behaviour: email visibility toggles, the shared PDF render, mobile tab redesign, date formatting aligned between form and PDF. If you fork, you inherit the job of re-applying your changes across those rendering updates, and rendering code is the part most likely to change. Upstreaming a template or a locale is cheaper than maintaining a divergent branch. Running the hosted version costs nothing and carries no maintenance, which is the honest baseline to compare a fork against.

Editorial conclusion

Adopt EasyInvoicePDF if you want a self-hosted, browser-only invoice generator with customizable templates and you can live with AGPL-3.0. Do not adopt it if you need server-side batch invoicing, a documented JSON import/export format, or a permissive licence for a closed product. Before committing, verify that the shareable-link feature does not push invoice data to a backend, and confirm which template files you would need to modify for your own branding.

Official sources

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