Forem: Graham Sutton

I Spent a Week Fighting HTML-to-PDF. Here’s What Finally Worked.

Graham Sutton — Wed, 06 May 2026 21:25:51 +0000

I’ve been building a property inspection platform with a friend of mine who’s an inspector. One of the requirements was deceptively simple:

Generate PDF reports.

That’s the deliverable inspectors send to insurance companies, banks, clients, etc. So the PDFs need to actually look good. Lots of photos, cover pages, tables of contents, structured sections, all that fun stuff.

My friend uses Spectora right now and honestly their PDFs were pretty good. So I figured, alright, let me build something similar.

I thought this would take maybe a day or two. It ended up taking me about a week and the PDF output is still brittle.

First, I started with:

wkhtmltopdf
Puppeteer
PDF libraries (DomPDF, mPDF, FPDF, etc)
CSS @print media query layouts

Nothing really ever worked right. Text would sometimes randomly overflow pages. I would constantly make an update to CSS and then generate a PDF and back and forth and back and forth. Headers and footers were also pain. One thing that drove me insane was that I wanted headers and footers on most pages, but not on the cover page or table of contents.

Sounds reasonable, right?

Turns out with a lot of these tools, it’s basically: headers everywhere or headers nowhere at all.

At one point I had CSS media queries inside of templates inside of rendering configs and I genuinely stopped understanding what controlled what anymore.

The thing that changed my perspective

I started googling around for alternatives. Eventually I stumbled across Carbone.

What caught my attention wasn’t even the API. It was the idea behind it.

Instead of trying to force HTML into behaving like a print layout engine, they just let you design documents in Word.

And honestly, that makes a ton of sense.

Word has spent decades solving pagination, print layout, margins, page breaks, etc. Meanwhile I was knee-deep in HTML hoping the **** document is going to render neatly this time.

I tried Carbone and the output was actually pretty good.

Then I got to the pricing and concurrency limits:

€29/month
1000 renders
only 2 concurrent documents

That was kind of the moment where I thought (where we have all thought):

“Honestly, I kinda want to try building this myself.”

So I built one in Rust

Originally this was not supposed to become a product.

I just wanted PDFs for our inspection app.

I built a very rough prototype in Rust using Handlebars-style templating and started experimenting with:

DOCX templating
image replacement
loops
conditionals
PDF conversion pipelines

The weird part is it actually started working surprisingly well.

Like, suspiciously well.

I expected this project to collapse under its own complexity almost immediately, but instead I kept adding features and the results kept getting better.

And because I was building it specifically for property inspection reports, I was stress testing it with exactly the kind of PDFs that normally become nightmares:

image-heavy documents
cover pages
tables
long narratives
repeated sections
inconsistent data

At some point I realized:

a) this was solving my own problem really well
b) other developers probably hate this problem too

So I turned it into a real thing.

The biggest thing I learned

The actual PDF rendering isn’t the hard part. The hard part is everything around it. Especially images.

If your document has 40 remote image URLs in it, that's 40 requests to download images that may be several MBs to even GBs, which if performed all at the same time, could run the instance out of memory during rendering.

The rendering itself can be fast, but if the server has to fetch dozens of images over the network first, that becomes the bottleneck very quickly.

I solved this by creating an buffer that parses for image URLs in your data and batches requests to pre-fetch them before rendering, which enables you to send those 40 images without crashing the instance.

Another optimization that makes a huge difference was simply allowing images to be passed directly as base64 instead of URLs. That forgoes the issue altogether and removes a bunch of network overhead entirely.

Right now I can render around 15 one-page PDFs/sec in production with simple templates (i.e. lots of data and <= 2 remote images).

Why I ended up making Rendrr

The more I worked on this, the more I realized others could benefit from this.

There are tons of HTML-to-PDF solutions.

But if you want:

truly WYSIWYG documents
Word-based templates
APIs
decent performance
sane pricing
concurrency that isn't intentionally limited

then there are surprisingly few options.

That's why I built Rendrr.

(Did I just self-promote? Yes. Yes, I did. Sue me. I work hard and how else is anyone else going to know it exists if I don't talk about it?)

Right now it’s still early access. I’m mostly focused on stability and making the core experience solid before I start piling on more features.

That said, I do have some ideas I’m excited about:

MCP server to generate and edit Word templates (there is a skill already available though that does the same thing!)
live previewing/editing in the dashboard
maybe PowerPoint templating eventually

We'll see what users demand first.

Anyway

This is my first SaaS that I've launched and would love to get some honest feedback about it. There's a free plan available. If you happen to hit your limit, feel free to reach out to me at graham@rendrr.io and I'll gladly up your limit for the small exchange of telling me what you like/don't like so far.

Thanks for reading!

Raw SQL Migrations Library

Graham Sutton — Fri, 13 Sep 2019 21:38:14 +0000

Where I currently work, we operate on a stack of mostly PHP and PostgreSQL. Our framework was written in ZF1 (it's legacy), and our deployment process for keeping our database changes version-controlled is quite tedious and complex.

Outside of work, I love using frameworks like Laravel and Rails and one of the features I really love from both of these is migrations. Since our legacy application at work doesn't have this concept, I started thinking of ways to take this modern approach and apply it to our legacy app.

Since we cannot convert our entire application over to one of these frameworks (it would be a major overhaul), I looked into some options like Phinx and Flyway for possible integration, but these options were not really compatible with our app (for various reasons that would deserve their own post).

At our company, we make very heavy use of PostgreSQL: complex procedures, triggers, views, multiple schemas, data warehousing, etc... we power everything on it. Many migration-type libraries usually have some abstraction layer that doesn't really support the full range of these database features. For example, Rails migrations are written in Ruby and then converted down to SQL before execution; same with Laravel and PHP. This isn't a bad thing, but these types of abstractions don't truly support the wide range of database features (particularly procedures) and are typically limited to just creating tables, indexes, and constraints.

So, I decided to task myself (for fun mostly) with trying to build a migrations library that would run on raw SQL, and lo and behold, I actually got a simple concept going! The underlying CLI is written in PHP, but you write and execute migrations in raw SQL.

I figured that maybe a lot of other people could get some use from such a library, and so I put it up on GitHub a while back but never really shared its existence with anyone. So today, that is what I am doing.

I am really looking for people who would like to help make it better. I think it's a good start, but I know a truly great tool isn't built by one person alone. Feel free to criticize, praise, or contribute!

Exodus Migrations Library: https://github.com/grahamsutton/exodus

Laravel's factory method, but for JavaScript.

Graham Sutton — Sun, 02 Jun 2019 14:40:08 +0000

When I became exhausted with trying to create tons of mock API data on the fly for my Node projects, I created a simple little script that would let me define the skeleton of the JSON structure I wanted without having to copy, paste, and modify each individual record.

This script is now available as an NPM package that does almost exactly what Laravel's factory method does except for JavaScript. It's lightweight and great for stubbing APIs in your Vue and React projects, too!

Link to the repo: https://github.com/grahamsutton/factory