fulgur — (noun, Latin) lightning, flash of lightning.

I've been building fulgur, an HTML-to-PDF engine written in Rust. No headless browser, no Chromium, no WebKit — just an HTML parser, a layout engine, and a PDF writer, glued together with a pagination layer.

The current numbers (v0.5.14, 200-page document):

• 190 ms end-to-end
• 57 MB peak memory
• Byte-identical PDF output across runs

This post is the story of how it got there: why I started it, what it's built on, what it can do today, and how I've been working with AI tools to ship it as a solo project.

Why build yet another HTML-to-PDF tool?

For years, wkhtmltopdf was the default. It's now archived, and the WebKit version it bundles has been frozen for years. Modern CSS doesn't really land there.

The mainstream replacements all have tradeoffs:

• Headless Chromium / Puppeteer / Playwright — gorgeous output, but you're shipping a browser. Cold start is slow, memory footprint is huge, and "just spin up Chrome in a container" stops being fun the moment you need to render thousands of PDFs a day.
• WeasyPrint — solid CSS Paged Media support, but Python and not particularly fast on big documents.
• Hosted services (Gotenberg, DocRaptor, etc.) — great until you can't send the data off-box, or until the per-PDF bill gets uncomfortable.

What I actually wanted was something that fit on the same server as my app, started instantly, and didn't blow up a Kubernetes pod's memory limit halfway through a 200-page report.

That's the niche fulgur is going after.

The "aha" moment: Blitz + Krilla

The unlock was realizing I didn't have to write a layout engine or a PDF writer from scratch. Two excellent crates already exist in the Rust ecosystem:

• Blitz — an HTML rendering engine from the Dioxus project. It does HTML parsing, CSS style resolution, and layout (via Taffy and Parley). It's not a full browser — no JS runtime, no networking — which is exactly what you want for a PDF tool.
• Krilla — a high-level PDF writing library. It hides the gnarly parts of the PDF spec behind a clean API: text, shapes, images, gradients, tagged PDF for accessibility, font subsetting, the works.

So the question became: can I write the glue between "Blitz says this box goes here" and "Krilla, please draw text at this coordinate" — plus a pagination layer that splits content across pages?

Turns out: yes. That glue is fulgur.

HTML / CSS
    │
    ▼
Blitz  ── DOM → style resolution → Taffy layout
    │
    ▼
DOM → Pageable conversion (Block / Paragraph / Image)
    │
    ▼
Pagination  ── split the Pageable tree at page boundaries
    │
    ▼
Krilla  ── draw each page → PDF Surface
    │
    ▼
PDF bytes

While I was at it, I needed @media print support for things like print-only stylesheets. So I sent PR #390 to Blitz and it got merged upstream. Huge thanks to the Blitz maintainers — fulgur literally wouldn't be feasible without their work.

Performance

Here's where it gets fun. After landing a font caching change (wrapping the loaded font database in Arc so we don't reload Noto Sans JP for every page), the numbers shifted from "okay" to "actually production-ready":

Two things stand out:

1. Memory is the real story. 57 MB to render a 200-page document means you can run fulgur inside a normal-sized container without thinking about it. WeasyPrint and wkhtmltopdf use 3–4x more.
2. 190 ms is fast enough that PDF generation stops being a background job. You can render on the request path for most documents.

Why isn't it even faster? The pipeline does a 2-pass render so that running headers/footers can show "Page X of Y" — page count needs to be known before laying out the page chrome. That cap is structural; I'd rather have correct page numbering than shave another 50 ms.

What v0.5.14 actually does

The version on Zenn was v0.3.0. A lot has shipped since:

• Automatic page splitting with full CSS pagination control (break-before, break-after, break-inside, orphans, widows)
• CSS Generated Content for Paged Media (GCPM) — page counters, running headers and footers, margin boxes
• Built-in template engine — pass an HTML template + JSON data, get a PDF. Powered by MiniJinja.
• Image embedding — PNG, JPEG, GIF
• Custom font bundling with subsetting — TTF, OTF, TTC, WOFF2
• PDF bookmarks auto-generated from h1–h6
• PDF metadata — title, author, keywords, language
• External CSS injection, page sizes (A4 / Letter / A3) with landscape, configurable margins

Quick CLI tour

Install via npm (no Rust toolchain needed):

npx @fulgur-rs/cli render -o output.pdf input.html

Or via Cargo:

cargo install fulgur-cli

Basic usage:

# Convert a file
fulgur render -o output.pdf input.html

# Pipe HTML in
cat report.html | fulgur render --stdin -o report.pdf

# Page options
fulgur render -o output.pdf -s Letter -l --margin "20 30" input.html

# Bundle fonts and CSS
fulgur render -o output.pdf -f fonts/NotoSansJP.ttf --css print.css input.html

Template + JSON

This is the part I'm most excited about, because it maps cleanly onto how AI agents want to generate documents.

invoice.html:

<h1>Invoice #{{ invoice_number }}</h1>
<p>{{ customer_name }}</p>
<table>
  {% for item in items %}
  <tr><td>{{ item.name }}</td><td>{{ item.price }}</td></tr>
  {% endfor %}
</table>

data.json:

{
  "invoice_number": "2026-001",
  "customer_name": "Acme Corp",
  "items": [
    { "name": "Widget", "price": "$10.00" },
    { "name": "Gadget", "price": "$25.00" }
  ]
}

fulgur render -o invoice.pdf -d data.json invoice.html

An AI agent emitting JSON is a very natural fit for this interface — it doesn't need to know anything about PDFs, just the data shape.

As a library

use fulgur::engine::Engine;
use fulgur::config::{PageSize, Margin};

let engine = Engine::builder()
    .page_size(PageSize::A4)
    .margin(Margin::uniform_mm(20.0))
    .title("My Document")
    .build();

let pdf = engine.render_html(html)?;

Honest about where it is today

I want to be upfront about something: fulgur is not "throw any HTML at it and get pixel-perfect PDFs." It's not a browser. It's a pagination-aware renderer that supports a curated subset of HTML and CSS, and within that subset it produces clean, predictable output. Push outside the supported surface and you'll see weird layout, missing styles, or things that just don't render.

That's a real limitation today, and I'm not going to pretend otherwise.

But here's the bet I'm making — and the reason I think the curated-subset approach is fine, even good, in 2026:

The consumers of this API are increasingly going to be AI agents, and they already know the web platform.

LLMs have absorbed an enormous amount of HTML and CSS during training. If you give an agent a JSON payload and say "render this as an invoice PDF," it will reach for <table>, flex, grid, standard typography — the well-trodden parts of the web platform. Those are exactly the parts I'm prioritizing.

So the design target isn't "render any webpage as a PDF." It's "give an AI agent a templating surface where its existing web-standards knowledge produces the right document, deterministically, without spinning up a browser." Different goal, different tradeoffs, much smaller surface to get right.

To keep this honest rather than aspirational, fulgur runs against the Web Platform Tests suite — the same conformance suite the major browsers use. The pass rate is the metric I'm tracking the supported-subset against, and it climbs with every release. "What does fulgur actually support?" stops being a vibe and becomes a number.

Current numbers, to be transparent about it:

Yes, those are low. They're also the real numbers, on the parts of the spec fulgur cares most about (Paged Media and multi-column layout). The point of putting them on the table is that they're now a number that can go up, release after release — not a hand-wavy "we support most of CSS." If you file a bug pointing at a specific WPT case that should pass, that's directly actionable.

That's where fulgur is heading. Today it's already useful for invoice-shaped, report-shaped, form-shaped documents. The supported surface grows — measurably — with every release.

Determinism, on purpose

One feature I want to call out separately: byte-identical output for identical input.

This sounds boring, but it's huge for CI. If your golden PDFs change byte-for-byte every time you re-run the pipeline, diffing them is useless. Fulgur's pipeline (Blitz → Taffy → Parley → Krilla) is deterministic by design.

The one caveat is fonts: Blitz currently calls fontdb::Database::load_system_fonts() for SVG <text> elements, which means the same HTML can produce different output on machines with different system fonts. The repo ships a pinned Noto bundle and a fontconfig setup that keeps examples/*/index.pdf byte-identical across CI, so you can get reproducible output today by pointing FONTCONFIG_FILE at a controlled font set.

How I'm building it: AI-driven solo dev

Fulgur is a one-person project, but it's been built with a fairly heavy AI tooling setup. A few things that have actually worked:

Claude Code + superpowers

I do most of the implementation work in Claude Code with the superpowers plugin. The loop is:

1. Brainstorm — talk through the design with Claude before writing anything
2. Plan — turn the design into a stepwise implementation plan
3. Implement — execute the plan, one chunk at a time

The brainstorm-then-plan structure keeps the agent from wandering off. It's also surprisingly good at catching "wait, this design has a hole" before any code is written.

term-cli for the debugger

term-cli lets an AI agent drive interactive programs through tmux. The killer use case for me is letting Claude Code drive a real debugger.

Without it, agents tend to fall back to println! debugging and spiral. With a debugger they can inspect variables directly, set breakpoints, and resolve "why is this layout offset wrong" in one shot. The behavior change is dramatic.

AI code review

I run Devin Review and CodeRabbit on every PR. PDF spec edge cases and CSS layout corner cases are exactly the kind of thing where having a second pair of eyes matters, and as a solo maintainer I don't have human reviewers. Both tools have caught real issues, especially around pagination edge cases.

It's not a substitute for a strong test suite — fulgur has a fixture-based golden PDF test setup — but it's a useful additional layer.

What's next

A few things on the roadmap:

• More language bindings — Python (PyO3) and Ruby (Magnus) are already shipping; Node.js (napi-rs) is next.
• More GCPM — there's still a long tail of CSS Paged Media features
• A proper benchmarking harness that runs in CI on every release

The repo is here, with full README, threat model, and contribution guide:

👉 github.com/fulgur-rs/fulgur

Site: fulgur.dev

If you've been looking for a way to generate PDFs at scale without paying the Chromium tax, give it a try. Stars, issues, and PRs all very welcome — and if you hit a CSS edge case that breaks things, please open an issue with a minimal repro. That's the fastest path to fixing it.