Three different products are sold as a PDF/UA API

Search for a PDF/UA API and you get a list. Work down it and the entries turn out not to be the same kind of product. One takes a finished PDF and rebuilds its structure. One takes your data or your HTML and emits a tagged file. One tells you whether a file conforms. They all appear under the same query, they are priced as though they were substitutes, and picking the wrong shape costs an integration.

Three questions separate them. What goes in, what comes out, and what proves it.

What goes in: remediation or generation

Remediation starts from a PDF that already exists. It infers structure from the page, builds a tag tree, and writes a new file. This is the right purchase when the documents are already made: a decade of published reports, scanned material, output from a system nobody can change.

ConvertAPI's accessibility automation is shaped this way. Its own description of the input step is "securely bring in digital and scanned PDFs", with OCR for the scanned case. PDFix sits in the same category.

Generation starts upstream, from HTML or from structured data, and never produces an untagged file in the first place. This is the right purchase when the documents are a feature of your product: invoices, statements, contracts, tickets, anything a template emits at volume.

The distinction matters more than it sounds, because remediation is priced and scoped per document while generation is a property of a template you fix once. A team that generates 400,000 statements a month and buys remediation has bought a per-document cost for a per-template problem. A team with a 40,000-file archive that buys generation has bought nothing at all.

If your documents come out of code, you want the generation shape. Everything below is about that half of the field.

What comes out: tagging is not conformance

Almost every vendor in the generation half will tell you it produces PDF/UA. Read the claim precisely, because "tagged" and "conformant" are different states and the gap between them is where files fail.

Tagging gives the file a structure tree. PDF/UA-1 also requires, among other things, a document title set in the catalog rather than only in the metadata, a declared natural language, decorative content marked as artifacts rather than left untagged, and an XMP identifier asserting the conformance level. A tagged file missing a document title is not a conformant file, and a missing title is one of the most common automatic failures there is.

PDF/A is a separate axis with its own requirements, mainly an output intent, fully embedded fonts, and matching metadata. The two combine, and a file can satisfy either without the other.

None of this is exotic and the free tools reach it. Chromium can emit tagged output, Gotenberg converts to both PDF/A and PDF/UA, and WeasyPrint produces both natively. So does the paid field. PdfBroker generates both from HTML using WeasyPrint and says so plainly. PDF Generator API claims "fully tagged, PDF/UA compliant outputs" from templates, HTML, or existing PDFs.

Format output is not the scarce thing. It stopped being the scarce thing a while ago.

What proves it: the axis most pages skip

Here is the test that actually separates the field. Open a vendor's PDF/UA page and look for the name of a validator.

Checked on 24 August 2026: PdfBroker's page states the output is "PDF/A and PDF/UA compliant" and does not mention running a validator against it. PDF Generator API's accessibility page describes the tagging it performs and names no validation tool. Neither is doing anything wrong; they are claiming what they claim. But a claim about the format is not the same artifact as a check on the file, and the check is the part that survives a template change.

ConvertAPI is the counterexample and worth crediting: its page describes "built-in checks plus optional integration with PAC 2024" and producing "a validation report for QA". That is verification bundled into the product. It sits on the remediation side of the input axis, so it is not a substitute if your documents are generated, but on this axis it is doing the right thing.

Why the check matters more than it sounds: conformance is not stable. It is a property of the interaction between your markup and the renderer, so it regresses. A designer adds a decorative background, a developer swaps a heading for a styled div, a template gains a layout table, and the next 200,000 documents are non-conformant with nothing in the pipeline objecting. The failure is invisible in every viewer that is not a screen reader. You find out from a complaint or an audit.

A validator in the render path turns that into a build failure. And it can only settle about two thirds of the standard: the Matterhorn Protocol splits ISO 14289-1's 136 failure conditions into 89 machine-checkable and 45 that need a human. Two thirds is still the two thirds that regresses silently.

Test any of them in ten minutes

Do not take a capability matrix, this one included, on faith. The whole field is checkable with veraPDF, which is open source and runs locally.

1. 1Build one page of HTML with the constructs that actually break.

   A data table with real <th scope> header cells, an image with meaningful alt, a second image you intend as decorative, a two-column layout, and a heading level that skips.

2. 2Send it to the candidate API

   with whatever PDF/UA option it offers.

3. 3Run veraPDF's PDF/UA-1 profile over the result

   and read the failures rather than the pass/fail.

4. 4Check the two things that catch most files regardless:

   does the document have a title, and does the XMP declare a conformance level.

5. 5Change the template the way a designer would,

   resend, and see whether anything in the vendor's response tells you something broke.

Which step discriminates

Step 5. Steps 1 to 4 you can run against every vendor on the list, including the free rail, and you will learn more in an afternoon than any comparison page can tell you.

Price is not the axis you think

The assumption that compliance carries a premium does not survive the numbers. Checked 24 August 2026: PdfBroker includes PDF/A and PDF/UA on its €8.95/month plan at 1,500 requests, and excludes them only from its free tier. PDF Generator API does gate its Accessibility API by plan, unavailable on its two cheapest tiers and included from €520/year upward, which is the one real feature gate we found. PolyDoc's entry plan is $9/month for 1,000 conversions with the compliance options on every tier including the free one.

The short version

The clearing price for compliance output sits at or below ordinary entry pricing for an HTML-to-PDF API. If a vendor asks for a large premium purely for the format, that is a pricing decision rather than a cost.

What to ask before you integrate

• Does it take HTML or data, or only a finished PDF?
• Does it name a validator, and can you get that validator's output back?
• Can a failed check fail the request, or does it return the file anyway?
• Does PDF/UA combine with PDF/A in one call, or are they separate conversions?
• Where does the rendering happen, and is the input retained?

Where PolyDoc sits

Generation from HTML, PDF/A and tagged PDF/UA-1 in the same call, and veraPDF in the request path with an enforcing mode, so a non-conforming file comes back as an error instead of a document. That last one is the reason it exists, because it is the step the rest of the generation field leaves to you, and it is what makes step 5 above something the pipeline does rather than something you remember to do.

It does not remediate an existing archive, and it does not resolve the 45 failure conditions only a human can judge. See the accessible PDF overview and the PDF/UA guide for the exact surface. The free plan is 150 conversions a month without a card, which is enough to run the ten-minute test above against it.

Vendor capabilities and prices above were read from each vendor's own public pages on 24 August 2026 and are linked so you can re-check them. Pages and plans move; verify before relying on any line here, including ours.