kelvinzhang

The sync was so seamless I didn't even realize it was playing from my own device at first

After a year since v1, I’m open-sourcing htmldocs, a React-based library for building PDF documents using modern web development tools. Write document templates in JSX, style with Tailwind, and render them to pixel-perfect PDFs with a Chromium pipeline—no more LaTeX headaches or Word/Google Docs limitations.

I originally built this because I needed a better way to generate invoices and tailor resumes to job descriptions dynamically. Existing solutions had major trade-offs:

- Google Docs/Word → Easy but lack APIs & version control

- LaTeX → Structured output but painful syntax & no API

- Figma → Flexible but not designed for automation

With htmldocs, you can:

- Define document templates and props in JSX (just like web components)

- Use modern CSS (flexbox, grid, Tailwind, etc.)

- Render server-side via a headless Chromium pipeline

- Upload templates for remote PDF generation via an API

Most of the world still runs on PDFs—contracts, reports, invoices, resumes, etc. It’s time we had a developer-first approach to document generation, just like we build for the web.

What frustrations have you had with existing document solutions? Would love to hear your ideas, experiences, and feedback.

Offline isn’t a priority at the moment but can be done in the future by packaging with Electron.

Typst is great but there are a few key differences:

- full CSS support, allowing for more customizability and familiar styling without a learning curve

- less tailored towards academic use-cases are more towards personal/business use-cases like resumes, invoices, reports. Also adding a template gallery in the near future.

- has a templating engine and API baked in

- can use JS packages and ecosystem (ex. icon sets, fonts, etc.)

The long term goal of this project is to make HTML/CSS the defacto way of typesetting PDF documents. I’ll definitely keep it running for as long as I can.

The web version is just the initial step, and will likely open source for people who want to self-host and to increase adoption. For pricing, will probably adopt a model similar to Overleaf where it’s free for most users and maybe charge for team collaboration or have an enterprise license.

Fixed! Sorry about that

I think in the long term, HTML/CSS will win out once there's better support for CSS Paged Module Level 3, and you'll be able to achieve that requirement with just

    @page :left {
        margin-left: 20mm;
        margin-right: 10mm;
    }
    
    @page :right {
        margin-left: 10mm;
        margin-right: 20mm;
    }

instead of needing to install/import different LaTeX packages. I think for most of my current use-cases level 2 has been sufficient but I can see if I can include Paged.js polyfill support by default so there's more support for customizability on that front.

Pricing info is in a modal under the user dropdown, it's currently based on a monthly credit system. If there's another pricing model you'd prefer, let me know!

You can probably get away with Pandoc depending on your use-case, this is primarily built for:

- having a web editor interface without needing to re-run a CLI command

- people who don't want to deal with packages/dependencies on their own system

- users that just want an affordable and easy-to-use API to generate PDF documents instead of having to set up their own server <> task queue <> worker system which would usually cost more

- in the future, teams that want to collaborate together on a document

I think it should be on the <ul> tag. See https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_li...

This is a great suggestion and I feel dumb for not thinking of this earlier. Thanks!

Nice catch, I copy/pasted that from a previous project and forgot to remove - should be fixed now.

TOS is pretty general and just there for legal reasons, tl;dr feel free to use as you see fit as long as it's not for anything illegal.

We actually ran off of WeasyPrint at first but switched to Chromium due to emojis not rendering properly, poor flexbox support, no custom fonts, and other differences between the HTML you'd see in a browser vs. the generated PDF.

WeasyPrint implements its own rendering engine and might support some specific @page properties that Chromium does not but given the complexity of CSS and web browsers, you're generally better off sticking with Chromium due to its history.

Also – an added benefit is that we can use JS libraries like FontAwesome, Bootstrap, KaTeX, etc. which is where other HTML to PDF libraries fall flat.

We definitely need more ways to build quick web UIs for Python code. Looks sick!

Love the idea of an open source Retool. Excited to try it out

Congrats on the launch! Super cool stuff

Hey, I'm one of the engineers behind Dropbase. Currently all imported data needs to be structured, which means that the data needs to be formatted in either values, records, index, or column orientations (see https://pandas.pydata.org/pandas-docs/stable/reference/api/p...). Right now we can only auto-detect between those formats, but in the future we're looking to accept unstructured data as well.

Hi, the dots are currently generated on a per capita basis, although it not be as visible since we use a log scale. We're working on adding per capita tooltips though!

Hey there! For the map to display properly your device needs to be in landscape mode; if you're using the site on a phone, please make sure "auto rotate device" is turned on and try again. Sorry about that :)