Filecook vs PDFShift at a glance
| Filecook | PDFShift | |
|---|---|---|
| Rendering engine | Latest Chromium | Chromium |
| JavaScript execution | Yes | Yes |
| Image output (PNG / JPEG) | Same endpoint, same quota | Screenshot capability available |
| Pricing unit | Per successful render | Credit-based, counted per 5 MB of output |
| Free tier | 500 renders / month | 50 credits / month |
| Failed renders billed | No | Check current terms |
| Self-hosted option | Perpetual licence available | Not offered |
Competitor details checked August 2026 from public documentation and pricing pages. Products change — verify current terms with PDFShift before deciding.
Where the two genuinely differ
Both products solve the same core problem with the same engine, so the choice comes down to commercial model rather than rendering fidelity.
- How you are counted. PDFShift meters credits against output size, so a heavy report can consume several credits. Filecook counts one successful render as one render regardless of how large the file is, which makes forecasting simpler when document size varies.
- Free tier depth. 500 renders a month is enough to run a small production workload, not just a trial.
- Deployment options. If compliance requires the renderer inside your own network, Filecook offers a perpetual on-premise licence.
Where PDFShift may suit you better
It is a mature, well-documented product with a long track record and features like password protection and watermarking called out prominently. If those are load-bearing requirements today, evaluate both against your actual document set before switching — and if PDFShift already works for you, there is no urgent reason to move.
Migrating
Both APIs take a JSON body with an HTML or URL field and return the document bytes directly. In practice a migration is a change of endpoint, auth header, and options key names — typically an afternoon, and you can run both in parallel while you diff the output.