Ask HN: What is nowadays (opensource) way of converting HTML to PDF? • Hacker News Board

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#141

Post by user3939382 » Thu, Oct 02, 2025, 11:54 AM UTC

Aachen wrote: post #138

ratelimitsteve wrote: post #96

Earlier quoted context omitted.

>Sometimes you want one, sometimes, the other. This is the part that the top commenter missed. Instead they decided that one format is "nice" and the other, by implication, isn't. I find PDFs a lot easier to keep organized en masse, I like that I can use them on any of my devices and it's easy for me to use them when I'm doing in-depth reading such as an ebook. Doubly so because my ereader also does text to speech an…

None of that sounds related to the format? - A text to speech engine should work better with the original html structure where it sees bold tags, headings, and full sentences ra- ther than broken-off ones - Keeping PDFs organised, how would that differ from keeping any other filetype organised? I don't understand what difference you, "by implication", attribute to a file ending in .html or .pdf for being able to hand…

HTML could do everything PDF does in theory but it doesn’t in practice because the tooling doesn’t exist.

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#142

Post by crazygringo » Thu, Oct 02, 2025, 1:27 PM UTC

user3939382 wrote: post #141

Aachen wrote: post #138

Earlier quoted context omitted.

None of that sounds related to the format? - A text to speech engine should work better with the original html structure where it sees bold tags, headings, and full sentences ra- ther than broken-off ones - Keeping PDFs organised, how would that differ from keeping any other filetype organised? I don't understand what difference you, "by implication", attribute to a file ending in .html or .pdf for being able to hand…

HTML could do everything PDF does in theory but it doesn’t in practice because the tooling doesn’t exist.

My exercise bike can play Doom on its display in theory.

Theory doesn't matter here, tooling and standards do. And PDF doesn't just have the tooling for highlighting and annotations, it has the standards for them so that tools support them in an interoperable way. A highlight made with one tool can be removed with another, without altering the underlying content.

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#143

Post by jerjerjer » Thu, Oct 02, 2025, 1:57 PM UTC

Aachen wrote: post #131

nine_k wrote: post #71

Earlier quoted context omitted.

PDF is literally digital paper. HTML has logical structure, it can adapt to different displays, etc. Sometimes you want one, sometimes, the other.

When do want the digital paper when you can have the more flexible one?

When I want it to be displayed in the exact same way everywhere.

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#144

Post by cxr » Thu, Oct 02, 2025, 2:02 PM UTC

crazygringo wrote: post #124

cxr wrote: post #109

Earlier quoted context omitted.

The W3C standardized HTML annotations years ago. There's a difference between a standard not existing versus people pretending it doesn't exist because it's not implemented by Chrome.

That's different. Those are a data structure defining annotations that are meant to be stored externally. They're not part of an HTML file like PDF annotations are. They're meant more for live collaborative commenting within a shared online space, not for making private portable annotations like PDF does. And it's not a Chrome thing. I don't think any browsers support it, do they? It's not really clear there's a need…

So is there a need for it or isn't there?

> That's different. Those are a data structure defining annotations that are meant to be stored externally.

The protocol is a separate standard.

The format is JSON-LD. Putting JSON-LD into HTML isn't a question mark. (There's info at W3C.org about how to do that, too. Not that it's necessary. You can guess what it says.)

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#145

Post by ratelimitsteve » Thu, Oct 02, 2025, 2:33 PM UTC

Aachen wrote: post #138

ratelimitsteve wrote: post #96

Earlier quoted context omitted.

>Sometimes you want one, sometimes, the other. This is the part that the top commenter missed. Instead they decided that one format is "nice" and the other, by implication, isn't. I find PDFs a lot easier to keep organized en masse, I like that I can use them on any of my devices and it's easy for me to use them when I'm doing in-depth reading such as an ebook. Doubly so because my ereader also does text to speech an…

None of that sounds related to the format? - A text to speech engine should work better with the original html structure where it sees bold tags, headings, and full sentences ra- ther than broken-off ones - Keeping PDFs organised, how would that differ from keeping any other filetype organised? I don't understand what difference you, "by implication", attribute to a file ending in .html or .pdf for being able to hand…

maybe html can do all of these and it will only cost me the time it takes to build the app, but right now PDF does all of those things for me, here today in my pocket, for $15. Which is nice.

I'd love to see a text to speech engine that pronounces formatting but I think it might be more complicated than learning to pronounce something boldly. Am I yelling? Am I keeping my voice low but adding intensity? Can you automate answering that question in a way that's mostly correct most of the time? If something is in italics am I whispering, stage whispering, emphasizing or merely saying the title of an existing work out loud? It's a fundamental abuse of a text formatting engine to try to use it for speech formatting, you either have to use the existing tags for things they were never intended for or you have to start adding tags like and vs . That being said, an html-independent form of emotional text annotation might actually be a good idea as the inevitability of synthesized human voices being a part of our daily lives takes hold.

I find PDFs easier to organize than HTML because HTML is any number of files referencing each other across a directory structure that can have any size or shape, and a PDF is a single file. If I'm searching my library for Bob Wilson, I want his books to show up and I want them to have his picture in them if that's how the book was published but I don't want Bob_Wilson.jpeg to show up as a result. I could automate print to PDF from html or use the tool someone else posted in order to condense my saved HTMLs to single files but that's more processing time and effort in order to get what I already have from a PDF

Syncing position across HTML files may be doable, but syncing position across PDFs is done. You're absolutely right that that has nothing to do with the format but the (implied) question I was answering when I brought it up was why I would sometimes want one and other times want the other. That's why.

Finally, and probably the only one that really matters inasmuch as all the other reasons can be coded around but this one cant: the places I get documents distribute them in PDF, mobi and epub but almost never in HTML

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#146

Post by ratelimitsteve » Thu, Oct 02, 2025, 2:34 PM UTC

crazygringo wrote: post #142

user3939382 wrote: post #141

Earlier quoted context omitted.

HTML could do everything PDF does in theory but it doesn’t in practice because the tooling doesn’t exist.

My exercise bike can play Doom on its display in theory. Theory doesn't matter here, tooling and standards do. And PDF doesn't just have the tooling for highlighting and annotations, it has the standards for them so that tools support them in an interoperable way. A highlight made with one tool can be removed with another, without altering the underlying content.

I would love an exercise bike that runs doom. Maybe link my movement speed in-game to how fast I pedal, with a joystick on one of the handlebars to move and a couple buttons on the other one to shoot and reload. So far every exercise bike game is just bike race, which I'll admit is a close fit for the existing hardware and probably the first idea I'd have too but it gets boring after a while.

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#147

Post by NanoWar » Thu, Oct 02, 2025, 3:07 PM UTC

delduca wrote: post #65

https://gotenberg.dev

We use this in production and it's very stable. It also supports background gradients which we wanted to use so badly :-) Can recommend

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#148

Post by dredmorbius » Thu, Oct 02, 2025, 3:13 PM UTC

haft wrote: post #24

A reverse of this question; what is the best way to convert pdf to html? We are required by accessibility law to make our PDFs WCAG compliant however it would be easier to convert these to HTML.

This reduces to parsing PDFs, which is an unsolved hard problem.

At low volumes, my preferred approach is to select and extract text (copy/paste, perhaps using the poppler library for larger-scale work), dump that to plain-text and convert that (manually / scripted) to Markdown. From there you can get to PDF or pretty much any other format through tools such as pandoc.

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#149

Post by Towaway69 » Thu, Oct 02, 2025, 3:14 PM UTC

stared wrote: post #132

What's your goal? Print it? Archivize it? Send it via email? Read it on another device (which)? Depending on that, there are different solutions and trade-offs. For example on how to deal with pagination.

OP wants to archive 5k a month --> https://news.ycombinator.com/item?id=45440073

Re: Ask HN: What is nowadays (opensource) way of converting HTML to PDF?

#150

Post by dredmorbius » Thu, Oct 02, 2025, 3:19 PM UTC

Shortcutting much of the discussion here (what are you goals / why would you do that / don't use format X): a key problem is that neither HTML (as published on today's Web) nor PDF are reliable as canonical document formats. Tagged-markup such as Markdown (or otherlightweight markup languages) or LaTeX (or other heavy markup languages) are far more robust. Markdown has its variants, but all are pretty simple and easy to produce. LaTeX is slightly more complex, but remains quite straightforward for simple works.

Once you've got an appropriate canonical version in any of these options, you have an embarassment of riches to convert to any given document format (what I call endpoints) you'd care for: PDF, HTML, RTF, DOCX, or many, many others. I generally reach for Pandoc first, which itself, yes, of course, often relies on additional tools/libraries to parse or generate endpoints, but is quite versatile.

You can simplify the intake of HTML by stripping out cruft. Readability, Beautiful Soup, or other HTML filtering tools can target the core content and metadata you most likely want.

Otherwise, think through what you're doing and why to more narrowly define your goals and tools. E.g., if you want a faithful printed representation of a mainstream-browser-rendered page (that is, Google Chrome), you'd probably do best to use its print-to-PDF options (mentioned several times here). If you want to extract core text, filtering out much of today's WWW cruft will be a high priority.