boxes
360 rounded, bordered, filled boxes
jasy
15.4 ms
22 KBreact-pdf
339.2 ms
pdfmake
13.2 ms
jsPDF
9.4 ms
all 2 pages · p95 18.8 ms
benchmark · pure typescript · run it yourself
How fast is jasy? Here is everything we measured.
Six documents, four engines, every comparison held to the same text on the same pages. jasy is a PDF engine in pure TypeScript - no headless browser, no WASM, no JVM - and it is what @jasy/vue and @jasy/nuxt render with.
- jasylays out
Flexbox layout, in pure TypeScript.
Works the document out itself - line breaks, pagination, kerning, SVG. No headless browser, no WASM, no JVM.
- react-pdflays out
Flexbox layout, as React components.
The same job through Yoga and a React tree. The closest comparison on this page.
- pdfmakelays out
Declarative layout, one document object.
Works it out too, with its own column and table model. Kerns, and takes SVG markup directly.
- jsPDFyou lay out
A drawing API. No layout.
You work out every coordinate and every page break. That is why it is quick here, and why two cases are blank.
- 5.9x
- faster than react-pdf
- 1.6x
- faster than pdfmake
- 10 / 12
- never behind
Both figures are geometric means, which is the correct average of ratios. jsPDF is not in them - it draws where these lay out, and an average across the two would mean nothing. Its comparison has its own section below, losses included.
- measured
- 8 September 2026 at 18:17 UTC
- versions
- @jasy/pdf 1.0.0-beta.3@react-pdf/renderer 4.5.1pdfmake 0.3.11jspdf 4.2.1
- machine
- 13th Gen Intel(R) Core(TM) i5-13400 x16
- method
- median of 25 runs, node v24.20.0
The six documents
Bars are to scale within a case, against its slowest engine. Every pairing was checked for the same words on the same pages before a ratio was printed.
canvas
40 charts x 24 bars, drawn with the imperative pen
jasy
3.9 ms
7 KBreact-pdf
13.9 ms
pdfmake
3.3 ms
jsPDF
3.0 ms
all 4 pages · p95 4.7 ms
document
a report: repeating header/footer, 24 paragraphs, 90 table rows
jasy
16.2 ms
9 KBreact-pdf
167.2 ms
pdfmake
26.4 ms
jsPDF
5.5 ms
all 4 pages · p95 19.4 ms
svg
120 vector marks - paths, strokes, joins
jasy
6.9 ms
3 KBreact-pdf
47.2 ms
pdfmake
35.7 ms
jsPDF
cannot render this - no SVG support (that is svg2pdf.js, a separate library)
all 1 page · p95 7.6 ms
text
180 flowing paragraphs - line breaking and pagination
jasy
58.5 ms
18 KBreact-pdf
148.8 ms
pdfmake
108.6 ms
jsPDF
19.1 ms
all 13 pages · p95 60.1 ms
typography
120 paragraphs in an embedded TrueType - real kerning + ligatures
jasy
34.4 ms
28 KBreact-pdf
102.5 ms
pdfmake
51.4 ms
jsPDF
cannot render this - no kerning, so the same words do not land in the same places
all 7 pages · p95 36.3 ms
where jasy is behind
jsPDF is 2.1x faster than jasy.
It draws where the others lay out, and drawing is cheaper. There is no defect on either side - you are the one doing the layout. In the report case that is 73 lines of jsPDF against 41 of jasy: every y coordinate, every page break, and the header redrawn after each new page. Both are on this page; read them rather than take the count.
That is the whole trade. You pay roughly forty milliseconds on thirteen pages, and stop writing that loop. Two of the six documents it cannot produce at all - the SVG case needs a second library, and it never kerns, so the same words do not land in the same places.
what keeps this honest
A benchmark written by the author of one of the engines is worth nothing until it shows what it did to catch itself.
So here is every rule this harness enforces - including the two that cost us the numbers we would rather be printing. They stay in.
- 01
Every engine draws the same document
caught us twiceSame words, same count, same pages - checked before a ratio is printed, and the runner refuses to print one otherwise. It has earned its keep twice, both times on our own mistakes: a case that handed react-pdf a cell too short for its line, so it drew no labels at all while the page count still matched; and a header spacing we had set on one side only, which put a whole body 8pt lower.
- 02
Every paragraph is different
cost us 39 pointsA benchmark that repeats one string measures caching, not layout. Ours did, and the repetition helped react-pdf far more than us - on the same machine and the same day, the flowing-text case came out 45% in its favour with one repeated paragraph and 6% with 180 different ones. Real documents have no identical paragraphs, so neither do these.
- 03
The settings are converted, not assumed
the tedious oneThe same word means different things in each of them: a line height multiplies the font size in jasy, the font's own natural height in pdfmake, and is not inherited into nested text at all in react-pdf. None of that is a fault - it just has to be converted, or the documents break in different places. Every conversion is pinned in the case with the reason beside it.
- 04
We switch our own features off
our handicapjasy keeps two lines of a paragraph together at a page break; jsPDF has no such rule. So it is turned off in the report case, on our side and react-pdf's. Handicapping ourselves is what makes it the same document.
Run it yourself
The harness, the six documents and the raw JSON behind this page are in the repository. It pins the versions it compares against, and prints the machine it ran on.
git clone https://github.com/jasy-pdf/jasy
cd jasy/bench
pnpm install
pnpm benchYour document is not among the six? That is the fair objection to any benchmark, and the answer is a pull request - a case is one file with one function per engine.
One machine, one day, six documents. Your numbers will differ - which is the point of publishing the harness rather than only the result.