[HN Gopher] Ask HN: What is nowadays (opensource) way of convert...
___________________________________________________________________
Ask HN: What is nowadays (opensource) way of converting HTML to
PDF?
I'm using wkhtmltopdf but it is painful to work with? what are
other people using nowadays? i.e canva or other tools?
Author : hhthrowaway1230
Score : 99 points
Date : 2025-09-28 14:52 UTC (3 days ago)
| zja wrote:
| pandoc
| hhthrowaway1230 wrote:
| doesn't pandoc rely on some engine itself?
| brudgers wrote:
| Curious why that matters to you?
|
| I mean everything has dependencies (some of the solutions
| elsewhere require Chrome and other common solutions require
| the JVM). At least Pandoc is GPL.
| kakokiyrvoooo wrote:
| It matters because pandoc is not rendering the website to
| pdf, it converts the html to latex and then uses a latex
| engine to render the pdf.
| brudgers wrote:
| Forgive me but I don't understand why that matters to you
| and am trying to understand what the issue with Latex is.
|
| Because lots of things work this way. For example
| compilers built on LLV uses an intermediate language and
| Python uses byte code.
|
| I suspect some html to pdf tools go through postScript.
| kreetx wrote:
| There are multiple ways to "depend", so if pandoc executes
| some external tool all of the work then might as well use
| that external tool directly. You will get more control over
| how the conversion happens, know for what search for when
| in trouble etc.
| brudgers wrote:
| My understanding and experience is that Latex has a
| significant learning curve and Pandoc provides a more
| gentle front end.
|
| Of course Latex gives you fine control to hand tune the
| engine...but that doesn't seem like what the OP is
| looking for.
| cpach wrote:
| Yep, you need something like XeTeX in order to render the
| PDF.
| beeforpork wrote:
| Does pandoc do JavaScript? For stuff that is rendered (I don't
| want animated, interactive PDFs...).
| w10-1 wrote:
| To reinforce this: pandoc has been the go-to for a long, long
| time and they have encountered and addressed tons of issues,
| which is especially important for two underspecified and over-
| provisioned formats like HTML and pdf.
|
| Go through the revision and bug history to see a sample of
| issues you're avoiding by using a highly-trafficked, well-
| supported solution.
|
| The only reason not to use it is when they say they don't
| support a given feature that you need; and the nice thing there
| is that they'll usually say it, and have a good reason why.
|
| The other reason to use pandoc is that while you might
| currently want PDF as your outbound format, you might end up
| preferring some other format (structured logically instead of
| by layout); with pandoc that change would be easy.
|
| Finally, pandoc is extensible. If you do find that you want
| different output in some respect, you can easily write an
| plugin (in python or haskel or ...) to make exactly the tweak
| you need.
| throw03172019 wrote:
| I run chromium on my server and render the PDF from there using
| puppeteer.
| kappadi3 wrote:
| Puppeteer and Playwright are the main open-source options
| nowadays, both solid for HTML - PDF once your print CSS is
| sorted. Don't forget proper page breaks (break-
| before/after/inside) -- e.g. break-after: page works in Chromium,
| while always doesn't. For trickier pagination you can look at
| Paged.js, and I'd test layouts in Chrome/Edge before automating.
|
| Shameless plug: I run yakpdf.com, a hosted Puppeteer-based
| service if you want to avoid self-hosting.
| https://rapidapi.com/yakpdf-yakpdf/api/yakpdf
| johnh-hn wrote:
| Seconded. I went with C# + Playwright. I tried iTextSharp,
| iText, PDFSharp, and wkhtmltopdf, but they all had limitations.
| I had good results with Playwright in minutes, outside of
| tweaking the CSS like you mention.
|
| I documented the process here[0] if anyone needs examples of
| the CSS and loading web fonts. Apologies for the article being
| long-winded - it was the first one I published.
|
| [0] https://johnh.co/blog/creating-pdfs-from-html-using-csharp
| benoau wrote:
| Thirded, you can build this straight into your backend or
| into a microservice _very_ easily.
|
| You can also easily generate screenshots if that's more
| suitable than PDFs.
|
| You can also easily use this to do stuff like jam a set of
| images into a HTML table and PDF or screenshot them in that
| format.
| mightjustwork wrote:
| https://gotenberg.dev/ ...has been working well for me for the
| last few years. It's a headless instance of Google Chrome with a
| golang wrapper. Runs well in Docker or a cloud instance.
| hansonkd wrote:
| gotenberg is really rock solid for us. Easy to deploy as a
| docker container to any infrastructure.
| zikani_03 wrote:
| Seconding.. gotenberg has been solid for us. We also make use
| of it's convert from Word to PDF feature and it's been really
| solid.
| pabs3 wrote:
| Just print to PDF in a browser, or automate that using a browser
| automation tool. For a non-browser-based open source solution,
| WeasyPrint.
|
| https://weasyprint.org/
|
| For a proprietary solution, try Prince XML:
|
| https://www.princexml.com/
| rossdavidh wrote:
| +1 to weasyprint; I have used weasyprint with a django
| production system for a few years now, and it works well enough
| that I never have to think about it. I'm not doing anything
| fancy, though, but for me it has worked well.
| grounder wrote:
| WeasyPrint works really well for me. It can support all of the
| languages and fonts I need. I run it on AWS Lambda and in
| Docker as a web service.
|
| I previously used WKHTMLTOPDF, but it hasn't been supported for
| years and doesn't support the latest CSS, etc. It does support
| JS if you need it, but I'd probably look at headless Chromium
| or another solution for JS if needed.
|
| Edit: Previous post with some good discussion:
| https://news.ycombinator.com/item?id=26578826
| stuaxo wrote:
| This is my experience and recommendation too.
| sureglymop wrote:
| Prince XML looks nice but what about creating a PDF directly
| from a website? This often adds some problems, for example
| links still pointing to other pages on the web. But in my
| experience printing to PDF is often not good enough.
| chinathrow wrote:
| Yes, I did that for a recent small program. The @media print
| media query is powerful enough for most of the stuff I wanted
| to format nicely. Even page breaks are possible.
| jmyeet wrote:
| I've had excellent experience with Prince XML and poor
| experience with everything else I've tried. Prince is fast,
| robust and reliable.
|
| Yes it costs money. So does developer time.
| angst_ridden wrote:
| Agreed. Prince also has a lot of good features for headers,
| footers, page numbering, etc, that make it very powerful.
| jiehong wrote:
| Most website do not have a print CSS, so it doesn't print that
| nicely in PDF.
|
| But, I upvote weasyprint for that instead.
| rcarmo wrote:
| These two are the only right answers if you want a reliable,
| reproducible, relatively low resource experience. Running a
| browser engine has always been hard to maintain in the long run
| for me.
| thenews wrote:
| https://stirlingpdf.io also uses weasyprint !!
| sodimel wrote:
| +1 - Weasyprint is an excellent tool to make pdf from html
| content, and we're using it at work (with django) to export
| various documents.
| bluebarbet wrote:
| Seconded. In my eccentric workflow, I use Weasyprint to convert
| HTML emails to more portable PDFs. A surprisingly successful
| experiment.
| journal wrote:
| if you are doing html to pdf, you might also need the ability to
| merge. a few more features and you're better of with a commercial
| solution.
| crazygringo wrote:
| Merge what?
| pentium166 wrote:
| I assume combining 2+ documents. For example, attaching a
| cover page with document owner/version control/lifecycle
| information to an existing PDF.
| crazygringo wrote:
| That's the easiest thing in the world with free software.
|
| One way is to install poppler-utils and use pdfunite. There
| are many other open-source packages you can use as well.
| fogzen wrote:
| Don't. Show a web page and open the print dialog, and tell people
| to save as PDF. All major browsers support this, and the browser
| HTML to PDF code is the most robust and accurate.
| crazygringo wrote:
| There's nothing in OP's question that suggests this is a one-
| off operation in response to a user action.
|
| It's very likely to be a massive batch operation of a ton of
| HTML files that might not even be their own site.
| hhthrowaway1230 wrote:
| this is the case indeed
| chibbell wrote:
| That does make sense where possible. I do feel like OPs
| question is super relevant if you are doing anything where the
| PDF has to be rendered server side, like say as part of a
| larger data process when producing an exportable report in PDF
| format.
| Snawoot wrote:
| chrome --headless --disable-gpu --print-to-pdf
| https://example.com
| piptastic wrote:
| same: google-chrome --headless --disable-gpu --no-pdf-header-
| footer --hide-scrollbars --print-to-pdf-margins="0,0,0,0"
| --print-to-pdf --window-size=1280,720 https://example.com
|
| ended up using headless chrome specifically to make sure
| javascript things rendered properly
| HPsquared wrote:
| Can Chromium do this?
|
| Edit: it appears so-
| https://news.ycombinator.com/item?id=15131840
| nine_k wrote:
| Yes, routinely works for me.
| mmphosis wrote:
| Can Firefox do this?
|
| with an elaborate script that relies on xdotool
| andrehacker wrote:
| Yes, kind of...
|
| /path/to/firefox --window-size 1700 --headless -screenshot
| myfile.png file://myfile.html
|
| Easy, right ?
|
| Used this for many years... but beware:
|
| - caveat 1: this is (or was) a more or less undocumented
| function and a few years ago it just disappeared only to come
| back in a later release.
|
| - caveat 2: even though you can convert local files it does
| require internet access as any references to icons, style
| sheets, fonts and tracker pixels cause Firefox to attempt to
| retrieve them without any (sensible) timeout. So, running
| this on a server without internet access will make the
| process hang forever.
| nine_k wrote:
| Why, Firefox has a headless mode. It can't just print a
| document via a simple CLI command, you have to go for
| Selenium (or maybe Playwright, I did not try it in that
| capacity). Foxdriver would work, but its development ceased.
| jlokier wrote:
| Last time I explored this, Firefox rendered thin lines in
| subtly bordered tables as thick lines, so I had to use
| Chromium. But back then Chrome did worse at pagination than
| Firefox.
|
| So I used Firefox for multi-page documents and Chromium for
| single-page invoices.
|
| I spent a lot of time with different versions of both
| browsers, and numerous quirks made a very unpleasant
| experience.
|
| Eventually I settled on Chromium (Ungoogled), which I use
| nowadays for invoices.
| exabrial wrote:
| openhtmltopdf is what we're using. Some outdated versions.
| supersaw wrote:
| Been using this as well. It's worth noting that while the
| original project appears to have been abandoned, it has since
| been forked and is currently maintained here:
| https://github.com/openhtmltopdf/openhtmltopdf
| exabrial wrote:
| thanks, didnt know that!
| RiverCrochet wrote:
| If you don't really need the PDF but just want to archive pages,
| SingleFile is better. It'll capture the entire page to a single
| HTML file and I find this is better than the PDF if I don't want
| to print it. It's a browser extension, but there's also a command
| line version (https://github.com/gildas-lormeau/single-file-cli)
| that uses Chrome or Chromium's headless mode.
| haft wrote:
| A revers 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.
| haft wrote:
| 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.
| bencornia wrote:
| I have been using pdf2htmlex with some success.
| https://github.com/pdf2htmlEX/pdf2htmlEX
| drabbiticus wrote:
| This is really cool, so thanks for sharing. Since the
| motivating goal for the question you are answering is WCAG
| compliance, is the output of pdf2htmlex meaningfully more
| WCAG compliant?
| Aachen wrote:
| Please don't turn nice formats into a format that's similar to
| screenshots of text. Pandoc has an option to pack all images and
| styles needed to render the page into one html file:
| pandoc --self-contained input.html -o output.html
| agedclock wrote:
| Pandoc would be my preferred tool. It is excellent at
| converting between other formats as well.
| TylerE wrote:
| Being (not so easily) edited is often a feature, not a bug.
| guywithahat wrote:
| I was thinking this too, PDF's exist so people don't mess
| with the document. That said, it's still a clever feature,
| and pandoc can convert html into a pdf as well with a
| conversion engine. That said, I suspect it'll fail on
| anything sufficiently complex
|
| pandoc input.html -o output.pdf --pdf-engine=<your engine>
| ryandrake wrote:
| Is this really that much of a motivation in 2025? Maybe in
| 2000 you could publish a PDF with the assurance that only the
| people who paid for Acrobat would be able to edit it, but
| today, there are a lot of accessible ways to edit PDFs, I
| don't think I'd choose PDF if I for whatever reason wanted to
| limit others from editing.
| craftkiller wrote:
| If that is your goal, you should be cryptographically signing
| your documents with your PGP key. That way you actually have
| assurance the document has not been modified rather than just
| hoping someone hasn't modified the document. Additionally,
| PGP can sign anything so you are open to use whatever format
| you want.
| crazygringo wrote:
| Or, please do?
|
| I use PDF's so I can send them to my iPad to read offline,
| highlight them, annotate them, and then send them back to my
| filesystem with highlights and annotations intact.
|
| I sure can't do that with any "nice formats" like HTML or TXT
| or EPUB or MOBI.
| mr_mitm wrote:
| You could, though. What you are describing are features of an
| editor, not a file format. I can imagine a browser addon
| performing the same tasks.
| whenc wrote:
| PDF annotations sit within the file.
| mr_mitm wrote:
| I know, even though that depends on the editor. Okular
| for example places them in an extra file, last I checked.
| That's not unique to PDFs. HTML files are modifiable.
| There is nothing preventing an editor to put annotations
| in it as well.
| crazygringo wrote:
| PDF is designed for annotations in the file format. You
| annotate in one editor, you can change the annotations in
| another. You can always distinguish between original
| content and annotations. I see no indication that Okular
| stores highlights or annotations in a separate file, that
| would be bizarre.
|
| There is no mechanism for annotations in HTML or the
| other formats I listed. An editor would just be editing
| the original content in its own non-standardized, non-
| portable way, which is not desirable for a number of
| reasons.
|
| So when you say:
|
| > _What you are describing are features of an editor, not
| a file format._
|
| That is incorrect. It is an intentionally designed _and
| standardized_ feature of the file format.
| mr_mitm wrote:
| It definitely used to be bizarre then:
|
| https://superuser.com/questions/333378/where-does-okular-
| sto...
| ratelimitsteve wrote:
| turns out the default for okular is to save to an
| external file but there's a setting that can be changed
| to use the format correctly and store annotations within
| the file, which is universally compatible with other PDF
| readers. You can't really blame the format for someone
| using it wrong on purpose, and if you can then I'll just
| abuse HTML and the fact that I use it wrong will be
| evidence that it is, in itself, wrong
| cxr wrote:
| 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.
| circuit10 wrote:
| But in this case the flexibility of HTML is a negative
| because any layout shift would mess up the positions of the
| annotations, so fixing the layout (and making sure it's
| non-interactive) is helpful here
| nine_k wrote:
| PDF is literally digital paper. HTML has logical structure,
| it can adapt to different displays, etc.
|
| Sometimes you want one, sometimes, the other.
| ratelimitsteve wrote:
| >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 and syncs across devices
| so I can read on my tablet while I'm on the exercise bike
| and then switch to listening to the same book on my phone
| with minimal seams and without losing my place. It is, in a
| word, nice.
| moralestapia wrote:
| Please don't police what other people do.
| layer8 wrote:
| HTML+CSS+media files isn't a nice format, and much less
| portable through time and space than PDF.
| kelnos wrote:
| > _Please don 't turn nice formats into a format that's similar
| to screenshots of text_
|
| Converting HTML to PDF shouldn't result in an image wrapped in
| a PDF. Text will be preserved as text in the final PDF. (Unless
| the converter is garbage, of course.)
| thangalin wrote:
| Is this an xy problem? If you have the original document (in
| Markdown), one possibility would be to use my software,
| KeenWrite[1], to convert Markdown to XHTML then typeset XHTML to
| PDF via ConTeXt. See the user manual[2] for an example of a
| Markdown document typeset in this fashion, along with usage
| instructions.
|
| If you only have HTML to work with, you can also use Flying
| Saucer[3], which is what KeenWrite uses to preview Markdown
| documents when rendered as HTML. Flying Saucer uses an open-
| source version of iText[4] to produce PDF documents (from HTML
| source docs).
|
| Another possibility is to use pandoc and LaTeX.
|
| [1]: https://keenwrite.com/
|
| [2]: https://keenwrite.com/docs/user-manual.pdf
|
| [3]: https://github.com/flyingsaucerproject/flyingsaucer
|
| [4]: https://itextpdf.com/
| nicoburns wrote:
| https://github.com/plutoprint/plutobook was a recent Show HN and
| looks excellent
| ftchd wrote:
| the only thing I found to work reliably well is simply Chromium's
| print feature
| hhthrowaway1230 wrote:
| 5k pdfs a month for archival purposes, must be pdf, customers
| demand this
| bob1029 wrote:
| If your HTML is simply an intermediary to get you to a PDF, you
| could consider just skipping straight to building the PDF
| directly:
|
| https://pdfbox.apache.org
|
| This would be far more efficient than spinning up an entire
| browser and printing PDFs to disk.
| deaddodo wrote:
| Building PDF directly (unless you're creating documents,
| especially fillables) is non-intuitive. Most PDFs are people
| trying to capture live data in a cached manner. If not, using a
| preliminary format like Markdown/HTML/LaTeX/DocX/etc to
| generate your PDF is almost always more intuitive.
| ratStallion wrote:
| My website's content is xml, and I use Apache Fop to turn it into
| a PDF with page numbers and other nice things. It works nicely,
| but takes some setup.
| juice_bus wrote:
| I have Chromium shoved into an AWS Lambda Layer, when we need
| HTML to PDF conversion we shove it off onto that. It loads the
| HTML into Chromium then "prints" it to PDF.
| freedomben wrote:
| I'd love to go the other way: convert a PDF into a self contained
| HTML page that renders properly in a browser. It's been way
| harder than I thought it would. Any advice?
| drabbiticus wrote:
| > renders properly
|
| Depending on your requirements on both PDF input and HTML
| output, there is often no way to do this that is both easy and
| general. At it's core, PDFs are not designed to be universally
| reflowable.
| mr_mitm wrote:
| You could embed it as a base64 blob, embed PDF.js (which is
| included by browsers anyway, I think) and use that to render it
| in the HTML. But I realize you probably meant a static HTML
| without JavaScript.
| freedomben wrote:
| Yes ideally, but even this is helpful, thank you!
| lizimo wrote:
| If generating PDF dynamically is what you really care about,
| consider Typst. https://typst.app/ We use it in production to
| generate reports, and it is amazing.
| leephillips wrote:
| See https://lwn.net/Articles/1037577/ for a recent summary of
| what you can do with Typst.
| delduca wrote:
| https://gotenberg.dev
| Glyptodon wrote:
| The last time I had to do this I scripted a back-end that scaled
| up headless chrome browsers to render web pages to PDF. I think
| it was using Puppeteer, but was a few years ago. (FWIW the
| decision I think was mostly driven by the environment, I think
| there _are_ other options.)
| gigatexal wrote:
| pandoc is your friend.
| lucis wrote:
| jsPDF is a work of art https://parall.ax/products/jspdf
| handzhiev wrote:
| I'm surprised no one mentioned mPDF. Maybe php isn't very popular
| here :)
| cjm42 wrote:
| I've had decent results with html-pdf-chrome[0], which automates
| printing to PDF from Chromium or Chrome.
|
| [0] https://github.com/westy92/html-pdf-chrome/
| syngrog66 wrote:
| pandoc
| efnx wrote:
| pandoc
| ineedasername wrote:
| Ghostscript. Depending on specific needs it may be much more
| turnkey than Pandoc, which isn't actually doing much directly
| with things other than intermediating, iiuc. (LaTex) does the
| heavy lifting.
|
| Ghost script is working with postscript natively and will likely
| manage idiosyncrasies of web content better. It's got a decent
| ecosystem, command line, you can find gui's if that's your thing
| (no judgement, your lifestyle is none of my business).
|
| Many other good tools mentioned here as well, but if your asking
| because you need more, or fine grained (near infinite) control
| over the pdf composition, there's nothing OSS I can think of that
| approaches its capabilities.
|
| https://ghostscript.com/
| roschdal wrote:
| OpenPDF for Java https://github.com/LibrePDF/OpenPDF
| kragen wrote:
| I just wrote a quick HTML renderer in Python with ReportLab:
| https://GitHub.com/kragen/dercuano/blob/master/genpdf.py
|
| It only handles like 5% of HTML, but it's the 5% I was using.
|
| I've also had success producing PDFs with GhostScript from a
| PostScript file. PostScript is really easy to write, almost like
| SVG.
| Koffiepoeder wrote:
| If you want lots of differently styled templates, template
| management and editing/styling capabilites in word or excel (ie.
| you can just ask your customer/employer/.. to make an example
| document), I can really recommend Carbone [0]. I've been a happy
| customer for a few years now. Extra advantage is also that it
| also offers you excel outout generation as well, which is also
| often a requirement in applications. They have a SaaS offering as
| well if you'd like. They are open source though, so you can
| easily run a docker container!
|
| [0]: https://carbone.io/
| crsr wrote:
| Browserless have browsers as a service, and a dedicated pdf
| endpoint[0] you can call. Had really good experience with this.
|
| [0] http://docs.browserless.io/rest-apis/pdf-api
| Animats wrote:
| Print to PDF in the browser?
|
| My main use for that is printing appointment information,
| tickets, and product listings. The product listings are useful
| when trying to find in a store something that's supposedly
| available and in stock. Usually, only the first page is useful.
| There will be additional useless pages of irrelevant items,
| deals, and ads.
| fredguth wrote:
| I would use pandoc and convert to pdf using typst:
|
| ```
|
| pandoc input.html -t typst -o output.typ
|
| typst compile output.typ output.pdf
|
| ```
| trollbridge wrote:
| I wrote a solution in 2010 that used headless Firefox with some
| plugins to generate a PDF and then had the graphic designer write
| print CSSes. It was driven by Perl and was a convenient way for
| non-programmers to design forms.
|
| Unfortunately, that server and software stack is still around and
| still in production.
| znpy wrote:
| > Unfortunately, that server and software stack is still around
| and still in production.
|
| that means you did a good job.
| Dwedit wrote:
| 2010-era Firefox is probably plagued by security holes.
| busymom0 wrote:
| If you are able to do this on a Mac, you can load the html in a
| WKWebView and then use the function:
|
| createPDF(configuration:completionHandler:)
|
| https://developer.apple.com/documentation/webkit/wkwebview/c...:)
| estimator7292 wrote:
| IIRC LibreOffice has some command line tools to do all kinds of
| document conversion
___________________________________________________________________
(page generated 2025-10-01 23:01 UTC)