Polotno SDK vs PDFKit – drawing primitives vs a design schema

PDFKit is a JavaScript library for drawing PDFs imperatively: move here, set a font, write this string, draw that rectangle. It is small, free, dependency-light, and it has been the default answer for "generate a PDF in Node" for over a decade. Polotno SDK approaches the same output from the other end, with a declarative JSON schema and an editor that produces it. The choice comes down to who authors the layout.

Pick the one that matches how your layouts are made

Pick PDFKit if…

A developer owns the layout and it rarely changes. An invoice whose shape is fixed in code is a perfectly good fit, and adding a design tool on top would be overhead.
You want zero licensing and a tiny dependency. It is MIT and it is small. That is a real advantage and pretending otherwise would be dishonest.
You need imperative control over the document. Precise cursor positioning, custom flow logic, and per-primitive control are natural in code and awkward in a schema.
You are generating documents nobody designs. Receipts, logs, statements, and reports that come out of data and never pass a designer.

Pick Polotno SDK if…

Someone who is not a developer needs to change the layout. A marketer moving a logo should not require a deploy. That is the gap the editor fills.
Your users design the document themselves. PDFKit has no editing surface and is not trying to have one.
Templates need to live in a database. A design is JSON, so it is queryable, diffable, and versionable as data rather than as source code.
You need more than PDF. The same schema exports PNG, JPG, SVG, HTML, PPTX, GIF, and MP4.
You need print output. CMYK, spot colours, bleed, and PDF/X are built in rather than hand-rolled.

Writing instructions vs describing a result

1. Imperative against declarative

PDFKit is a sequence of instructions:

doc.fontSize(24).text("Invoice", 50, 50);
doc.fontSize(12).text(customer.name, 50, 90);

Polotno is a description of the result:

{ type: "text", text: "Invoice", x: 50, y: 50, fontSize: 24 }

The instruction list is more flexible. The description is easier to generate, store, hand to a non-developer, and render into other formats.

2. Who can change a layout

This is usually the deciding question. With PDFKit, changing where the logo sits is a code change, a review, and a deploy. With Polotno, it is a drag in an editor and a new row in a table.

3. Reading PDFs

PDFKit writes only. Polotno also reads, through @polotno/pdf-import, so an existing document can be brought in and edited. See PDF editing.

4. Cost

PDFKit is free. Polotno is licensed. If layout authorship never leaves the engineering team, that difference is hard to argue with.

When PDFKit is the right call

A fixed-format document generated from data by a backend, with no designer and no end user involved, is exactly what PDFKit is for. Reaching for an editor SDK there adds a licence and a dependency to solve a problem you do not have.

FAQ

Can Polotno generate PDFs without an editor?

Yes. The editor is optional. Build the JSON on your backend and render it through the Cloud Render API or @polotno/pdf-export under Node. See PDF generation.

Is Polotno's output vector like PDFKit's?

Yes, through @polotno/pdf-export. Note that the built-in store.saveAsPDF() is the raster path and flattens each page to an image; pick the vector one for selectable text.

Can I migrate a PDFKit layout to Polotno?

Not automatically. A PDFKit layout is code, not data, so it has to be rebuilt as a design. That is usually a short job for a fixed-format document and a good moment to hand the layout to whoever actually owns it.