DEV Community

Abdul Jabeer Shaik
Abdul Jabeer Shaik

Posted on

I built an HTML-to-PDF API in 6 weeks — here's what I learned

I got frustrated with PDF APIs that make you enter a credit card
before you can test anything. So I built my own.

It's called pdfkitt.dev — POST your HTML, get back a PDF.
1,000 free PDFs/month, no credit card required.

How it works

curl -X POST https://api.pdfkitt.dev/v1/pdf \
  -H "Authorization: Bearer pdfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"html": "<h1>Hello</h1>"}' \
  --output result.pdf
Enter fullscreen mode Exit fullscreen mode

That's it. No SDK required.

Tech decisions worth sharing

Playwright over Puppeteer — more stable browser pool
management, better CSS support for print layouts.

JavaScript disabled by design — security tradeoff. Works
perfectly for server-rendered HTML like invoices, reports, and
bank statements. Notion-style JS-heavy pages don't work —
and that's documented upfront.

Raw SQL over an ORM — kept it simple. Postgres on Railway,
bcrypt-hashed API keys, that's it.

Fastify over Express — faster, TypeScript-first, schema
validation built in.

The free tier decision

1,000 PDFs/month free was a deliberate choice. Most PDF APIs
give you 50-100 to "test" which isn't enough to actually
integrate and ship. I wanted developers to be able to go
from zero to production without ever thinking about paying.

What's working so far

  • Invoices, reports, bank statements render accurately
  • PowerShell integration works (had to document JSON handling explicitly — Windows devs have different defaults)
  • CSS print layouts, tables, page breaks all handled

What I cut from v1

SDKs, URL conversion, templates, webhooks, custom fonts,
screenshots, merge/split, OCR. All of it. Shipping one thing
well beats shipping ten things poorly.


Live at https://www.pdfkitt.dev — would love feedback from
anyone who's dealt with PDF generation pain.

Top comments (0)