Running on Workers
What it takes to run extract-pdf in a Cloudflare Worker, and the CPU limits that decide whether a PDF converts.
The default method with processor: "frontend" reads only the PDF text layer and needs no OCR, no model and no native code, so it runs entirely inside the Workers runtime. This site's own Worker does, at /demo.
| Concern | What to do |
|---|---|
| PDF.js | extract-pdf first tries to import PDF.js from jsDelivr. Workers do not allow runtime imports of remote code, so that fails and it falls back to the pdfjs-serverless package. List it as a dependency so it gets bundled. |
| Heavy optional engines | LiteParse (native addon), Granite Docling (@huggingface/transformers) and @napi-rs/canvas cannot run on Workers. Alias them to a module that throws, so they are not bundled and choosing one fails clearly. This site does it in aliases.ts; a plain Wrangler project uses "alias" in wrangler.jsonc. |
| Node globals | "compatibility_flags": ["nodejs_compat"] covers what the grab-url helper touches. |
| Request size | Cap uploads and fetched URLs, and stream the body so a large one is aborted early. |
CPU limits
Parsing is CPU-bound: PDF.js decodes every page and the block algorithm runs over every text item. For scale, the 15-page Attention Is All You Need paper (2.2 MB) takes about 1.4 s.
| Plan | CPU per request | What that means here |
|---|---|---|
| Free | 10 ms | Enough only for very small PDFs. Most real documents fail with "Worker exceeded CPU time limit" (error 1102). |
| Paid | 30 s by default, up to 5 min | Comfortable for normal papers and reports. |
On the Paid plan, set your own ceiling in wrangler.jsonc:
"limits": { "cpu_ms": 30000 }The Free plan rejects this setting on deploy. Waiting on the network, such as downloading a PDF, does not count toward CPU time. Memory is 128 MB per isolate, and the PDF bytes, PDF.js's parsed objects and the output HTML are all held at once, so keep the size cap well below that.