A document generation pipeline needs a template, a data source, and a renderer. Polotno gives you the template and the renderer, and stays out of the way on the data. Your team authors the template on a canvas and you store it as JSON, so a non-developer can change it without a deploy. The renderer turns it into PDF, PNG, JPG, SVG, HTML, or PPTX.
Who owns the template
Most document generation tools assume a developer writes the template as HTML and CSS, or as imperative drawing code. That holds up until the person who cares most about the layout cannot write either one.
In Polotno the template is a design. Someone authors it on the same canvas your users already see, and you store it as JSON in your database instead of as a file in your repository. When a logo, a legal footer, or a brand colour changes, someone opens the editor and fixes it.
Because the layout lives in the schema rather than in a stylesheet, your output holds its shape when data length changes. The element handles overflow, not a browser's pagination.
Positional documents, not flowing text
Document generation splits in two, and teams pick the wrong side often enough to be worth naming.
Flowing documents push content down the page. Multi-page reports, long invoices, statements, and contracts all work this way, and HTML pagination was built for them. An HTML-to-PDF service will serve you better there.
Positional documents get designed. Certificates, tickets, labels, badges, business cards, packaging, direct mail, and social assets all place every element deliberately, and the design breaks when something moves. A design schema models that well and CSS fights it.
What comes out
One template feeds every format the schema can render. The same certificate design becomes a print-ready PDF for your printer, a PNG for the confirmation email, and a JPG for the share card.
- PDF for print and archive, as vector output with selectable text. See PDF generation for the detail.
- PNG and JPG for previews, thumbnails, and email.
- SVG, HTML, and PPTX when the document stays editable downstream.
Print-oriented output supports CMYK, spot colours, bleed, and crop marks, and targets PDF/X-1a or PDF/X-4 for a commercial printer.
Where generation runs
Run it client-side and the document never leaves the user's machine, which suits anyone producing something for themselves out of sensitive data.
Run it server-side for volume and deterministic output. Host the renderer yourself when data residency matters, or hand the render leg to the Cloud Render API and skip operating a fleet. Both paths take the same JSON and produce the same document. See rendering modes for the trade-offs.
Typical pipelines
- Certificates and credentials issued on course completion, one per learner, from a design an instructor owns.
- Tickets and badges generated per attendee, with the QR code placed in the design rather than composited afterwards.
- Labels and packaging produced per SKU, print-ready, at whatever volume your catalogue runs to.
- Direct mail personalised per recipient and exported as PDF/X for the print vendor.
- Invoices and statements where you control the layout and the values come from a row.
For the patterns behind high-volume runs, see batch rendering at scale and building a production VDP pipeline.
What this does not cover
Document generation here means producing a document from a template and data. It will not fill the AcroForm fields of an existing PDF, run OCR over a scan, or assemble a document from a word processor file. There is no DOCX import. To open a document someone else made and change it, see PDF editing.
Related reading
- PDF generation: the PDF-specific path, with code.
- Create and manage templates via API: storing and updating templates programmatically.
- Cloud Render API: pricing and request shape for managed rendering.
- Rendering modes: client-side, self-hosted, and cloud compared.
