You know what's genuinely annoying? Spending an afternoon trying every HTML to PDF/UA converter you can find, only to end up with a PDF that looks perfect on screen but fails every accessibility check you throw at it. I've been there more times than I'd like to admit, and so have the folks posting over on r/software. The truth is, this problem is harder than it looks, and most guides skip over the bits that actually matter. So here's what works in 2026, explained properly.

TL;DR

No single click-and-done HTML to PDF/UA converter exists for Windows. Your best open source options are: (1) browser print-to-PDF for basic accessibility, (2) the html-to-pdf-ua Java tool built on openHTMLtoPDF for targeted PDF/UA and PDF/A-3A output, or (3) the PDFix Docker pipeline for the highest compliance confidence. All three require proper semantic HTML first.

⏱️ 13 min read ✅ Medium to High success rate 📅 Updated June 2026

Key Takeaways

An HTML to PDF/UA converter needs proper semantic HTML to work. Garbage in, garbage out.
Most popular tools (Puppeteer, wkhtmltopdf, jsPDF) do not produce PDF/UA-compliant output, no matter how good the PDF looks visually.
The html-to-pdf-ua Java tool is the best free, open-source option for Windows right now, but it needs JDK 21+ and correctly named .ttf font files.
PDF/UA-3 strict certification is very hard to achieve with open-source tooling alone. Verify output with PAC or Acrobat Pro.
PDFix via Docker gives the best compliance confidence but the SDK itself is not fully open source.

At a Glance

Difficulty: Advanced
Time Required: 15 to 60 mins depending on method
Success Rate: Medium to High depending on approach

Why Is Finding a Working HTML to PDF/UA Converter So Hard?

Here's the thing: most HTML-to-PDF tools were built to make PDFs that look right, not PDFs that are structured correctly for assistive technology. Visual fidelity and accessibility compliance are two completely different goals, and the majority of popular tools only chase the first one.

Tools like Puppeteer, wkhtmltopdf, and jsPDF are genuinely good at what they do. But what they do is render HTML visually and flatten it into a PDF. They don't emit the tagged PDF structure, document metadata, or reading order information that PDF/UA (ISO 14289) requires. So you end up with a PDF that a sighted user can read fine, but a screen reader just sees as a blob of unstructured content. Not great.

There's also a lot of confusion between PDF/UA, PDF/A, and their version numbers. PDF/A-3 is an archival standard (embedded fonts, self-contained). PDF/UA is an accessibility standard (tagged structure, reading order, metadata). PDF/UA-3 is the third revision of the accessibility standard. A document can comply with both simultaneously, which is what PDF/UA-3A means. Most open-source tools that claim any accessibility support are targeting PDF/UA-1 at best, and even that's often partial.

The other big gotcha is the HTML itself. Even the best HTML to PDF/UA converter can't magic up accessibility structure that isn't there. If your HTML uses div soup instead of semantic elements, has images without alt text, or tables without proper headers, the resulting PDF will fail accessibility checks regardless of which tool you use. Fixing the HTML is step zero, not an optional extra.

Font handling is another one that catches people out. The html-to-pdf-ua tool (more on that below) doesn't pull fonts from your Windows font library. It needs TrueType .ttf files sitting in a specific folder next to your HTML. Even if you have Arial installed system-wide, you still need to copy Arial.ttf into that folder. The tool reads font weight and style from the file name itself, so a file called ArialBold.ttf will be recognised as bold, but ArialBd.ttf might not be. Took me a while to figure that one out the first time.

And then there's the toolchain complexity. There's no GUI. No installer. You're working with Java JARs, Maven builds, patch files, and Docker containers. If that sounds like a lot, that's because it is. But once it's set up, it works reliably. If you're managing accessibility-critical documents regularly, it's worth the setup time. If you just need a quick one-off conversion, the browser method might be good enough.

HTML to PDF/UA Converter Quick Fix: Browser Print to PDF

Browser Print to PDF Easy

Fix your HTML semantics first
Before anything else, open your HTML file and check the structure. You need a lang attribute on the <html> tag (e.g. <html lang='en'>). Use proper semantic elements: <main>, <nav>, <header>, <footer>, <section>. Headings should follow a logical hierarchy (h1, h2, h3, not jumping from h1 to h4). Every image needs a descriptive alt attribute. Every form field needs a <label>. Replace any 'click here' link text with something meaningful.
Add print CSS for page layout
Add a <style> block in the HTML head with @page rules. For example: @page { size: A4; margin: 20mm; }. This controls page size and margins in the PDF output and avoids the converter making odd layout decisions.
Print to PDF in Chrome or Edge
Open the HTML file in Chrome or Edge (drag and drop works fine). Press Ctrl+P to open the print dialog. Set the destination to Save as PDF. Click Save. Recent Chromium builds do emit some basic tag structure, which is better than nothing.
Test with a screen reader
Open the resulting PDF in Adobe Acrobat Reader. Use the View menu to open the Tags panel and check the document structure. Run a screen reader (NVDA is free) over it and tab through the document to check reading order and link descriptions.

You'll get a partially tagged PDF that's better than an untagged one. Good enough for internal documents or a first draft. Not suitable for strict PDF/UA-3 certification.

Chrome's print-to-PDF is not guaranteed to meet full PDF/UA requirements. It's a reasonable starting point, not a compliance solution. For anything that needs to meet legal accessibility standards, use the intermediate or advanced methods below.

If you need a proper dedicated PDF tool to check, edit, and repair accessibility tags in existing PDFs, there are specialist PDF tools built exactly for this. They can fix reading order, add missing tags, and run conformance checks that free viewers can't do.

More HTML to PDF/UA Converter Options: The Java Tool

html-to-pdf-ua Java Tool Intermediate

Install JDK 21 or newer
Download a Java Development Kit (JDK) version 21 or newer from Adoptium or Oracle. Run the installer and let it set the PATH. Verify it's working by opening Command Prompt and typing java -version. You should see something like openjdk version 21.x.x. If you get 'java is not recognised', the PATH wasn't set correctly during install. Rerun the installer and tick the 'Set JAVA_HOME' option.
Set up your working folder and fonts
Create a folder for your project, something like C:\pdf-convert\. Put your HTML file in there. Inside that folder, create a subfolder called exactly fonts. Copy every TrueType .ttf font used in your HTML into that fonts folder. Yes, even fonts that are installed on Windows. The tool embeds them directly into the PDF and won't pull from the system font library. File naming matters: the tool infers weight and style from the file name. A file called RobotoBold.ttf will be treated as bold weight. A file called RobotoItalic.ttf will be treated as italic. If your font files have abbreviated names like Roboto-Bd.ttf, rename them to include the full keyword.
Check all links have title attributes
The html-to-pdf-ua tool specifically checks that links have title attributes as part of its PDF/UA criteria. Go through your HTML and add title='descriptive text' to every <a> tag. This is a PDF/UA requirement anyway (links must have a purpose that's clear from context or a label), so it's not extra work, just making sure it's done.
Download and run the JAR
Grab html-to-pdf-ua.jar from the project's releases page on GitHub. Put it in your working folder (C:\pdf-convert\). Open Command Prompt, navigate to that folder with cd C:\pdf-convert, and run:
java -jar html-to-pdf-ua.jar "yourfile.html"
The converter will process the file and produce output.pdf in the same folder. If you want PDF/A-4 instead of the default PDF/A-3A, append the flag:
java -jar html-to-pdf-ua.jar "yourfile.html" pdf/a-4
Verify the output
Open output.pdf in Adobe Acrobat Reader and check the Tags panel (View, Show/Hide, Navigation Panes, Tags). You should see a proper document tree with tagged headings, paragraphs, lists, and figures. Run the free PAC (PDF Accessibility Checker) tool for a proper conformance report. PAC will flag specific failures with reference to the PDF/UA clause they violate, which is much more useful than Acrobat's generic accessibility checker.

When it works correctly, you'll get a PDF with proper tag structure, embedded fonts, and PDF/A-3A compliance markers. PAC should report a clean or near-clean result for PDF/UA. This is the best free open-source HTML to PDF/UA converter option available right now for Windows.

The html-to-pdf-ua tool is built on top of openHTMLtoPDF, which is one of the very few open-source Java libraries that explicitly targets PDF/UA output. It's not perfect, and it needs patching for some edge cases, but it's the most mature open-source option in this space. Worth bookmarking the GitHub repo to watch for updates.

One thing to be aware of: the tool handles CSS reasonably well, but it's not a full browser renderer. Complex CSS grid layouts, flexbox, and some modern CSS properties may not render as expected. If your HTML was designed for screen display with heavy CSS, you might need a print-specific stylesheet. Add a <link rel='stylesheet' media='print' href='print.css'> reference and use that to simplify the layout for the PDF output. It's a bit of extra work upfront but saves a lot of head-scratching later. For more on managing print stylesheets and document output, see our guide to PDF document formatting on Windows.

Advanced HTML to PDF/UA Converter Fixes

Build the Patched openHTMLtoPDF Stack Advanced

Install JDK 21 and Apache Maven
You need both. JDK 21+ as above. Apache Maven can be downloaded from maven.apache.org. Extract it to somewhere like C:\tools\maven\ and add the bin folder to your PATH. Verify with mvn -version in a new Command Prompt window.
Download and patch openHTMLtoPDF 1.0.10
Download the 1.0.10 source archive from the openHTMLtoPDF GitHub releases. Extract it to a folder. Open Command Prompt in that folder and run git init. Copy the patch files from the HTML-to-PDF-UA repository (they're in the repo's patches folder) into this openHTMLtoPDF folder. Apply them with git am *.patch. If any patches fail to apply cleanly, check that you're using exactly version 1.0.10 of openHTMLtoPDF, not a newer or older release. Then run mvn clean install to compile, test, and install the patched library into your local Maven repository. This takes a few minutes and downloads dependencies on first run.
Build the HTML-to-PDF-UA JAR
Clone the HTML-to-PDF-UA repository. In that folder, run mvn clean package. Maven will compile the project against the patched openHTMLtoPDF you just installed locally. The output JAR will appear in the target folder. Use this JAR exactly as described in the intermediate section above.

You now have full control of the toolchain. You can modify the source, apply additional patches, and integrate the JAR into CI/CD pipelines or server-side batch processes.

PDFix HTML-to-PDF/UA via Docker Advanced

Install Docker Desktop for Windows
Download Docker Desktop from docker.com. It requires admin rights and WSL2 (Windows Subsystem for Linux 2). The installer will prompt you to enable WSL2 if it's not already active. After install, restart Windows and open Docker Desktop to confirm it's running.
Pull the PDFix image and run conversion
PDFix provides a Docker image that combines Google Headless Chrome (for pixel-accurate HTML rendering) with the PDFix SDK (for PDF/UA tagging). Pull the image with docker pull using the image name from the PDFix documentation. Then run conversion with something like:
docker run --rm -v C:\your-html-folder:/data pdfix/html-to-pdfua /data/yourfile.html /data/output.pdf
The exact command syntax is in the PDFix docs. The container renders the HTML with Headless Chrome and then applies PDF/UA structure via the PDFix SDK. Output lands in your mounted folder.
Verify with PAC
Run the output through PAC as described above. PDFix explicitly targets PDF/UA compliance, so results should be cleaner than the Java tool for complex HTML. That said, verify rather than assume. If you're producing documents that need to meet legal accessibility requirements (WCAG 2.1 AA equivalent for PDFs, for example), get a conformance report in writing.

This is the highest-confidence open workflow for PDF/UA output from HTML. The PDFix SDK is not fully open source, but the Docker integration pattern is open and scriptable, making it suitable for automated pipelines.

PDFix advertises PDF/UA compliance but may not explicitly differentiate between PDF/UA-1, PDF/UA-2, and PDF/UA-3 in all documentation. Always run PAC after conversion and check which version of the standard the output claims conformance with. If strict PDF/UA-3 certification is a legal requirement, consult the PDFix documentation directly or contact their support before committing to this workflow.

If you're running into issues with the Docker setup on Windows, particularly around WSL2 or file path mounting, our Docker Desktop Windows troubleshooting guide covers the most common setup problems. And if you're building this into a larger document management workflow, see our Windows document automation tools overview for context on where PDF conversion fits in the bigger picture.

Preventing HTML to PDF/UA Converter Problems

Most of the pain in this process comes from fixing things after the fact. Here's how to avoid it.

Start with accessible HTML, always. This is the most important one. If your HTML uses proper semantic structure from the beginning, every conversion attempt will produce better results. It's much easier to write <h2>Section Title</h2> than to go back and retrofit heading structure into a document full of styled divs. The PDF/UA standard (ISO 14289) maps directly to HTML accessibility concepts, so good HTML hygiene pays off twice.

Keep a fonts folder ready. Pick a standard set of fonts for your documents and keep their .ttf files in a central location. When you need to convert, just copy that folder. Don't rely on system fonts being available or named correctly. This alone will save you a lot of conversion failures.

Write print CSS early. Add @page rules and a print stylesheet to every HTML document template you create. Define page size, margins, and page break behaviour upfront. Retrofitting print layout onto a screen-first HTML document is genuinely annoying.

Script the conversion. Once you've got a working method, write a batch file or PowerShell script that runs the conversion with all the right options. Something as simple as a convert.bat that calls java -jar html-to-pdf-ua.jar %1 saves time and prevents mistakes when you're doing this regularly. Document which JDK version, which JAR version, and which Docker image you're using. Version mismatches are a common cause of subtle compliance failures that are hard to track down.

Validate every output. Don't assume a conversion worked correctly because the PDF looks right. Run PAC on every output, at least until you've established that your particular HTML template and font set produce clean results consistently. After that, spot-check periodically, especially after any toolchain updates.

HTML to PDF/UA Converter: Summary

Finding a working HTML to PDF/UA converter on Windows is genuinely difficult because the open-source ecosystem hasn't fully caught up with the PDF/UA-3 standard yet. But it's not impossible. For quick, non-certified accessibility improvements, the browser print-to-PDF method is fast and better than nothing. For proper open-source PDF/UA and PDF/A-3A output, the html-to-pdf-ua Java tool built on openHTMLtoPDF is the best free option available, provided your HTML is semantically clean and your fonts are in order. For the highest compliance confidence in an automated pipeline, the PDFix Docker workflow is the most reliable path, even though the SDK isn't fully open source. Whichever HTML to PDF/UA converter route you choose, validate the output with PAC before you ship anything that needs to meet accessibility standards.