4. Typst Beat a LaTeX Engine by 2.5x Warm and 523 Seconds Cold, and We Still Would Not Move Everything
We compiled matched 1,000 section documents in Typst and in LaTeX. Typst took 0.73 seconds, Tectonic took 1.81, and Tectonic's very first run took 523.05. Typst also used 2.8 times the memory doing it.
The WJS Desk
Sep 22, 2026 · 9 min read
Three parts of doing the work, and now the part where we say what we actually think. This is the benchmark against a real LaTeX engine, the independent validation of the claims that matter most, and the list of people who should not switch.
How we set the benchmark up
Our LaTeX baseline is Tectonic 0.17.0, a self-contained TeX engine installed with brew install tectonic. We picked it because a full TeX Live is a multi-gigabyte install that nobody would sit through for a comparison, and because Tectonic is what a person choosing LaTeX in 2026 would plausibly reach for.
We wrote a small Python generator that emits the same content twice, once as .typ and once as .tex: N numbered sections, three 90 word paragraphs each, and a summation formula. Same seed, same words, same order, A4, 11pt, 2.5cm margins on both sides. At N=1,000 that is 1,814,978 bytes of Typst source and 1,862,762 bytes of LaTeX source.
The honest caveat, up front. Identical input does not mean identical output. At 200 sections Typst produced 200 pages and Tectonic produced 106, because LaTeX's default leading and paragraph spacing pack text far more tightly than Typst's. These are not the same document. We report both the raw times and the per page numbers, and you should weight whichever matches how you would actually use them.
The numbers
Three runs of each, on the same Apple Silicon Mac, all timed with /usr/bin/time -p. The times below are the typical run.
| Document | Typst 0.15.1 | Tectonic 0.17.0 | Pages (Typst / Tectonic) |
|---|---|---|---|
| 1 section | 0.09 s | 0.17 s | 1 / 1 |
| 50 sections | 0.12 s | 0.25 s | 50 / 27 |
| 200 sections | 0.22 s | 0.50 s | 200 / 106 |
| 1,000 sections | 0.73 s | 1.81 s | 1,000 / 528 |
| First ever run | 1.61 s | 523.05 s | 1 / 1 |
| Peak memory at 1,000 | 858 MB | 300 MB | |
| PDF size at 1,000 | 2,923,761 B | 1,357,779 B | 2.92 / 2.57 KB per page |
Read that table carefully, because it does not say what a marketing page would say.
Warm, Typst is between 1.9x and 2.5x faster, and the gap widens with document size. Normalised per page, which is the fairer comparison given the layout divergence, the 1,000 section run works out at 0.73 ms per page for Typst and 3.43 ms per page for Tectonic. Per page output size is almost identical: 2.92 KB against 2.57 KB.
Cold is where the comparison stops being a comparison. Tectonic's first ever compile of a one page document took 523.05 seconds, eight minutes and 43 seconds, because it downloads TeX bundle resources on demand and a fresh install has none of them. Ours ended with 273 files and 42 MB in its cache. Typst's first run took 1.61 seconds, and that was the font scan.
Eight minutes and 43 seconds, for one page of Latin text and a summation. Then 0.17 seconds forever after.
And Typst loses on memory, clearly. 858 MB of peak resident set against Tectonic's 300 MB, on the same content. Typst holds the whole document in memory to support incremental compilation, which is precisely the feature that gives you 80 ms rebuilds in watch mode. It is a real trade, not an oversight, but if you are typesetting in a 512 MB container it is the number that will bite you first.
The result we did not expect
Typst 0.15.1 takes a --pdf-standard flag covering PDF/A-1b through PDF/A-4e and PDF/UA-1. Claiming conformance and conforming are different things, so we installed veraPDF 1.30.2, the industry validator, and checked:
brew install verapdf
typst compile --pdf-standard a-2b report.typ report-a2b.pdf
verapdf -f 2b --format text report-a2b.pdf| Output | Validated against | Result |
|---|---|---|
| typst --pdf-standard a-2b | PDF/A-2b | PASS |
| typst --pdf-standard a-4 | PDF/A-4 | PASS |
| typst --pdf-standard ua-1 | PDF/UA-1 | PASS |
| typst, no flag | PDF/A-2b | FAIL |
| typst, no flag | PDF/UA-1 | FAIL |
| tectonic, no package | PDF/A-2b | FAIL |
Three passes against an independent checker, from a flag. The two failures on unflagged output are the correct result and confirm the flag is doing real work rather than writing a label.
We then tried to get PDF/A out of the LaTeX side, using the standard pdfx package. Tectonic spent 281.34 seconds searching its bundle and returned ! LaTeX Error: File 'pdfx.sty' not found. That is a Tectonic bundle limitation rather than a LaTeX one, and a full TeX Live install would have the package. We are reporting it because it is what happened, not because it settles the question.
Two details worth knowing before you reach for this. PDF/UA-1 refuses to compile without a document title, which is the compiler enforcing an accessibility requirement rather than papering over it:
error: PDF/UA-1 error: missing document title
= hint: set the title with `set document(title: [...])`And Typst tags every PDF by default, not only the flagged ones. We measured what that costs by compiling the same file both ways: 25,031 bytes tagged, 16,548 bytes with --no-pdf-tags. A 51.3% size overhead, paid by default, in exchange for a baseline of screen reader structure. We think that is the right default and you should know it is there before you go hunting for why your PDFs are larger than you expected.
Reproducible builds, verified
Compile the same file twice and you get two different files, because the creation timestamp goes into the PDF. Typst honours SOURCE_DATE_EPOCH, and we checked with md5 rather than assuming:
typst compile --input repo=typst/typst onepager2.typ r1.pdf
typst compile --input repo=typst/typst onepager2.typ r2.pdf
md5 r1.pdf r2.pdf
SOURCE_DATE_EPOCH=1700000000 typst compile --input repo=typst/typst onepager2.typ r3.pdf
SOURCE_DATE_EPOCH=1700000000 typst compile --input repo=typst/typst onepager2.typ r4.pdf
md5 r3.pdf r4.pdfThe first pair differed. The second pair were byte identical, both 2c188d3e992cc47bc27aa3386332b752. If you sign or diff artefacts, set that variable in CI and stop thinking about it.
What else we confirmed works
A short list, because "it is fast" is worthless if the typesetting is thin. Each of these we compiled and looked at:
- Bibliographies in one pass. A
.bibfile and#bibliography("refs.bib", style: "ieee")produced a formatted reference list in a single compile. No bibtex run, no four pass dance. An unknown style name errors and exits 1. - Long tables. A 120 row table flowed across 3 pages with the header repeating, 87,783 bytes, no configuration.
- Two column layout with a full width float. Correct, including spill into a second page when we gave it enough text.
- Right to left text. Arabic with
dir: rtland a system font rendered correctly. - Images. An 85,725 byte PNG in a captioned figure produced a 102,087 byte PDF.
Where it loses, and where we would not use it
The output formats are pdf, png, svg, html and bundle. There is no docx and no odt, and no plan we could find for one. If any part of your workflow ends in somebody sending you tracked changes in Word, Typst does not solve your problem and no amount of compile speed will change that.
HTML export exists behind --features html, and the compiler itself tells you not to use it: "do not rely on this feature for production use cases". We exported a document and a level one heading came out as <h2>. The tracking issue is typst/typst#5512. Treat it as a preview, not a feature.
The version number is 0.15.1, and pre-1.0 means what it says. Within our own testing we hit the typst query subcommand being deprecated in favour of typst eval, and we ran a charting package whose own metadata targets compiler 0.13.1 rather than the 0.15.1 we were on. It worked. That is luck, not a compatibility guarantee.
The package registry has 1,617 packages. CTAN has tens of thousands. If your field has one LaTeX class that the journal requires, that class does not exist here, and porting it is your weekend.
On the project itself, we pulled the numbers rather than repeating the README. 56,184 stars, 449 contributors, 125 commits to main in 90 days, 1,292 open issues, Apache-2.0, created in September 2019. Healthy. But the top contributor has 2,551 commits and the second has 215, so this is one person's compiler with a community around it. And there is a company (typst.app) monetising a hosted editor on top of the open core, with a jobs page. That is a normal and reasonable structure. It is also a structure where the incentives around the free CLI can change, and you should price that in the same way you would for any open core tool.
Who should switch
- Anyone generating documents from data. This is the strongest case, and it is not close. Part two took eight rows of live API data to a typeset table and chart in 0.20 seconds with no build script.
- Anyone who needs validated PDF/A or PDF/UA output. One flag, passing an independent validator, is a better story than any alternative we are aware of.
- Anyone writing maths who has bounced off LaTeX. The syntax is
$ sum_(k=1)^n k^2 $and it took us no reference material to write. - Anyone who wants a document build in CI that finishes before the coffee does. One binary, zero system dependencies, 43 MB, deterministic output with one environment variable.
Who should not
- Anyone submitting to a venue with a mandated LaTeX class. The class is the requirement. The engine is not your choice.
- Anyone whose collaborators live in Word. No docx export, full stop.
- Anyone publishing to the web from the same source. Wait for HTML export to leave preview.
- Anyone running builds in a memory constrained container. 858 MB of peak RSS on a large document is a real constraint.
- Anyone who needs pinned, resolved, auditable dependencies. No lockfile, no resolver, and part two's version clash reported an error inside a package we never opened.
What we did not test
This matters as much as the numbers, because a number without its conditions is not a number. Everything here is macOS 26.5.1 on Apple Silicon, Typst 0.15.1, Tectonic 0.17.0, veraPDF 1.30.2. We did not test Windows, Linux, Intel Macs, or the typst.app hosted editor and its collaboration features. Our LaTeX baseline is Tectonic's bundle, not a full TeX Live, which is why the pdfx attempt failed and why you should not read that row as "LaTeX cannot do PDF/A". We did not test CJK typesetting, which is a common weak point and one we are not qualified to judge. We did not open the tagged PDFs in a screen reader: veraPDF validates structure, not whether a human can navigate the result. Our benchmark content is generated Latin text and one repeated formula, with no figures, cross references, citations or index, so it exercises text layout and very little else. And we ran each benchmark three times on one machine, which is enough to see a 2.5x gap and nowhere near enough to see a 5% one.
The verdict
Typst is the first thing in a long time that made us want to typeset something. The install is 2.20 seconds and 43 megabytes, the feedback loop is 80 milliseconds, the errors point at your line with a hint attached, and the scripting language means a document can regenerate itself from live data without a Makefile in sight. The PDF/A and PDF/UA results are the part we will still be thinking about next month.
It also has no lockfile, no Word export, an HTML mode the compiler apologises for, and a habit of treating a missing font as a warning while writing a confidently wrong PDF. None of those are dealbreakers. All of them are things you would rather find out here than in week three.
We are going to keep using it for anything that ends in a PDF and starts in a data file, and we are not going to suggest anyone rip out a working LaTeX pipeline to get here.
