pdfkit fails on python:3.13-slim because Debian 13 no longer ships wkhtmltopdf
Debian dropped wkhtmltopdf from testing on 2025-02-05, so pdfkit and imgkit calls on python:3.13-slim now fail for lack of a binary. The write-up urging headless Chromium comes from a vendor that sells a PDF service, and its crash test covered six pages.
The Engineer · Build desk
Share bar: the old wkhtmltopdf build crashed on 2 of 6 public pages printed, react.dev and a Wikipedia article, with a floating point exception and a segmentation fault. Headless Chromium printed all 6.
- Pages the old build crashed on, claim 8 2 of 6 public pages 33% computed
Pages the old build crashed on The rest of the 6
| Share | Part | Whole | Percent | Claim |
|---|---|---|---|---|
| Pages the old build crashed on | 2 public pages | 6 public pages | 33% (computed) | 8 |
What happened
- pdfkit, at about 3 million PyPI downloads a month, and imgkit are thin wrappers around the wkhtmltopdf binary.
- The last upstream build, 0.12.6.1, was made for Debian 12 and still runs on Debian 13 when installed by hand.
- In the same check that build crashed on 2 of 6 public pages, react.dev and a Wikipedia article, while headless Chromium printed all 6.
- pdfkit 1.0.0 carries CVE-2025-26240, CVSS 8.4 from CISA, where HTML passed to from_string can run JavaScript and read local files on the server.
Why it matters
- What it costs cost A Playwright migration puts browser timeouts, crashes and memory inside your own web worker, and the image carries the browser files as well.
- What it limits constraint Teams that keep the hand-installed Debian 12 build stay on a 2012 QtWebKit engine with no Promise, no fetch and no arrow functions.
- Who's exposed exposure Staying on pdfkit means waiting on a fix pull request that has sat unmerged since June 2026.
- Who has to decide decision Teams choose between shipping Chromium in the image and sending HTML to a paid hosted renderer, and the write-up's author sells one.
`apt-get install wkhtmltopdf` finds nothing on the base of the current python:3.13-slim image [4]. And in the author's check on 2026-10-12, `pdfkit.from_url()` stopped at "OSError: No wkhtmltopdf executable found", while imgkit stopped at "No wkhtmltoimage executable found" [5].
The wrappers hold no renderer of their own [1]. The error therefore appears where a call looks for the binary. Whether a pipeline notices at image build or at its first PDF depends on how its Dockerfile gets the binary.
The hand-installed 0.12.6.1 build is the cheapest stopgap. It is also a pin on a project whose repository was archived after its last push in November 2022 [2]. We think Chromium is the right destination for pipelines that can carry a browser in the image, and we would use the old build only for the length of the migration.
Two of six pages is a third [20]. The pages were public, and react.dev and a Wikipedia article were the two that crashed [8]. For that number to transfer, your documents would have to share whatever triggered the floating point exception and the segmentation fault. The author also sells a paid replacement, an Apify Actor called Website Screenshot API [16].
The write-up places CVE-2025-26240 in pdfkit 1.0.0, the wrapper, so pinning the old binary leaves it in place [9].
Playwright's `page.pdf()` covers the common pdfkit options [11]. In the author's run it produced a 792 x 612 point page box, which is Letter landscape [12]. The cost is disk. Chromium takes 389 MB [13] and the headless shell another 262 MB [14], which adds up to 651 MB [19] on the author's machine, before the system libraries that `--with-deps` installs. Those are one machine's figures.
The hosted route takes the browser out of your worker. The service accepts HTML strings up to 2 MiB each and returns one PDF per item. Empty or invalid items come back as rows with a reason and are not charged [17]. Each PDF gets a public download link, and the write-up does not say how long the link lives [17]. It also says margins default to zero, not to wkhtmltopdf's defaults, and that Chromium's page breaks will not match wkhtmltopdf's exactly [18].
What to watch
- Whether the open pdfkit pull request for CVE-2025-26240 merges and ships in a tagged release.
- Margin and page-break differences between wkhtmltopdf and Chromium output on production invoices, which the write-up says will not match exactly.
- Any published retention terms for the hosted renderer's public PDF download links.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption50
- Hype gap+15
- Incentives70
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
pdfkit (about 3 million downloads a month on PyPI) and imgkit are thin wrappers around the wkhtmltopdf binary.
- [2]
The wkhtmltopdf repository was archived after its last push in November 2022.
- [3]
Debian removed the wkhtmltopdf package from testing on 2025-02-05.
- [4]
Debian 13 is the base of the current python:3.13-slim image, so apt-get install wkhtmltopdf finds nothing.
- [5]
In a check on Debian 13 on 2026-10-12 with pdfkit 1.0.0, pdfkit.from_url() stopped at 'OSError: No wkhtmltopdf executable found' and imgkit stopped at 'No wkhtmltoimage executable found'.
- [6]
The last upstream wkhtmltopdf build (0.12.6.1, made for Debian 12) still runs on Debian 13 if installed by hand.
- [7]
In the same check, the old build's engine (QtWebKit from 2012) had no Promise, no fetch and no arrow functions.
- [8]
The old build crashed on 2 of 6 public pages printed (react.dev and a Wikipedia article, with a floating point exception and a segmentation fault); headless Chromium printed all 6.
- [9]
pdfkit 1.0.0 has CVE-2025-26240 (CVSS 8.4, from CISA): HTML passed to from_string can run JavaScript and read local files on the server that renders it.
- [10]
A fix pull request has been open on the pdfkit repository since June 2026 and is not merged.
- [11]
Playwright's page.pdf() covers the common pdfkit options.
- [12]
Run with Playwright 1.62, the PDF's page box is 792 x 612 points, which is Letter landscape.
- [13]
On the author's machine, Playwright 1.62's Chromium takes 389 MB on disk.
- [14]
Playwright 1.62's headless shell takes another 262 MB on the author's machine, plus the system libraries --with-deps adds.
- [15]
With a browser in the image, you own the timeouts, crashes and memory of a browser inside your web worker.
- [16]
The author builds an Apify Actor for this, Website Screenshot API, and discloses that it is theirs and paid.
- [17]
The Actor takes HTML strings up to 2 MiB each and returns one PDF per item, each with a public download link; empty or invalid items come back as rows with the reason and are not charged.
- [18]
Margins default to zero, not to wkhtmltopdf's defaults, and Chromium's page breaks will not match wkhtmltopdf's exactly, so a few real documents should be compared before switching.
- [19]
Chromium plus headless shell come to 651 MB on disk on the author's machine, before system libraries.
- [20]
2 of 6 pages crashing is one third of the sample.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.topdfkit says "No wkhtmltopdf executable found" on Debian 13: HTML to PDF without the binary
1 article · October 15, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.