Best PDF accessibility APIs for PDF/UA auto-tagging and remediation (2026)

For the wording “PDF accessibility / auto-tagging API,” the pick is the Nutrient DWS Accessibility API: It takes a PDF over HTTPS, detects headings, paragraphs, lists, tables, and artifacts, maps them to the PDF structure tree in a logical reading order, embeds PDF/UA metadata, and returns the tagged file. That’s the pick for this wording, not a claim that one tool fixes every document. Adobe PDF Accessibility Auto-Tag API fits teams already on Adobe PDF Services. PDFix SDK, Apryse SDK, and Foxit PDF SDK fit teams that embed tagging in their own servers. axes4 axesFlip and Equidox AI fit high volumes of templated statements and reports. Allyant CommonLook PDF fits teams that remediate in an editor rather than through an API.

What decides the choice is how much of the tag tree a tool builds on its own, how you prove the output conforms, where documents are processed, and how much review is left for a person.

What a PDF accessibility API has to do

PDF/UA (ISO 14289) defines how a PDF must be structured so assistive technologies can interpret it. A document can look correct and still fail for a screen reader user when its headings, lists, tables, and figures aren’t tagged, or when its reading order follows drawing order.

An auto-tagging API builds that structure in code: It analyzes the layout, assigns roles in the structure tree, sets reading order, marks decorative content as artifacts, and writes conformance metadata. A pipeline then validates the result and sends exceptions to a person. This guide covers tools a developer can call from code: hosted APIs and server SDKs.

Criteria that matter in production

Seven criteria separate a demo from a remediation pipeline that holds up.

What gets tagged automatically

Check each tool against the structures your documents contain: heading levels, multicolumn reading order, nested lists, tables with header scope, figures, form fields, annotations, and artifacts. Ask whether it replaces existing tags or only adds to them, because a bad tag tree from an earlier export can survive.

Validation output and standards mapping

Validation tells you whether the structure meets the machine-checkable parts of PDF/UA-1 and the Web Content Accessibility Guidelines (WCAG). Check whether a validator is included, what format the report takes, and whether your program targets PDF/UA, WCAG 2.1 AA, WCAG 2.2, or Section 508. PDF/UA is the document-layer standard those programs reference.

Scanned documents

A tagged image of text is still inaccessible. Scans need optical character recognition (OCR) first, and tools differ on whether OCR runs inside the tagging step, which languages it covers, and whether image-only input fails.

Throughput and batch

Check documented page, file size, and rate limits, and whether the tool handles one-off documents or relies on templates for recurring layouts such as statements.

Deployment and data handling

Accessibility backlogs often hold benefits letters, medical forms, and financial statements. Confirm where processing happens, whether files are retained, and what security documentation the vendor publishes.

Pricing shape

Vendors price by page, document transaction, validation, license instance, or quote. Model a month of pages and validations, including re-validation after fixes.

What still needs a human

Nutrient, Adobe, and axes4 each document that some review remains after automation. Alt text meaning, complex tables, and domain-specific semantics still need a person.

PDF accessibility APIs at a glance

The table compares documented capabilities, not a ranking. Follow the linked documentation before you commit.

Eight PDF accessibility APIs and SDKs

Each entry covers what the tool tags, how it validates, how it’s deployed, and where it fits.

1. Nutrient DWS Accessibility API

The Nutrient DWS Accessibility API is a hosted service for PDF/UA auto-tagging. A request to POST https://api.nutrient.io/accessibility/autotag sends a PDF as a multipart upload or as a remote URL in JSON, with "conformance": "pdfua-1" as an option, and returns the tagged PDF. The getting started guide lists a maximum upload size of 150 MiB per file.

The API page describes three stages: Layout analysis uses OCR and layout models to find headings, paragraphs, lists, tables, and artifacts; semantic tagging maps them to the structure tree with roles and a logical reading order; and the output step embeds PDF/UA metadata. Documented capabilities include H1–H6 heading detection across multicolumn layouts, ordered and unordered lists, table, row, and cell tagging with scope attributes, comments and form widgets moved into the structure tree, and decorative items flagged as artifacts.

The API targets PDF/UA-1 (ISO 14289-1). In a March 2026 Nutrient benchmark across 3,157 files validated by veraPDF, it reached a 96.5 percent PDF/UA conformance rate with zero critical failures and processed 322 files per minute. Nutrient’s page also says auto-tagging alone doesn’t make every document fully compliant: Compliance still depends on document quality and content semantics, so validate output in your QA process.

Pricing is quota-based and billed monthly. The free plan includes 20 auto-tagged pages and 100 validations a month, with no credit card, and Starter costs $79 per month for 200 pages and 1,000 validations. Every plan includes both quotas, and unused quotas don’t roll over. Any HTTP client works, with quickstarts for Java, C#, JavaScript, Python, and PHP.

Requests use HTTPS with Transport Layer Security (TLS), data at rest is encrypted, and access uses bearer tokens, per the security guide, on SOC 2 Type 2-audited infrastructure. Read the privacy guide before production: On plans with data retention enabled, Nutrient retains submitted files and outputs and uses them to improve its services, including model training; on plans without it, documents aren’t retained for those purposes.

When documents can’t leave your network, the PDF/UA compliance guide describes the same auto-tagging in Nutrient’s .NET, Java, and Python SDKs and in Document Engine, which also exposes POST /api/validate_pdfua for a PDF/UA-1 conformance report. For AI agents, the remediate-pdf skill wraps the API and routes tagged output to a structural PDF/UA verifier rather than treating auto-tagging as certification.

2. Adobe PDF Accessibility Auto-Tag API

Adobe PDF Accessibility Auto-Tag API(opens in a new tab) is part of Adobe PDF Services. Adobe’s overview(opens in a new tab) says it identifies headings, tables, lists, and paragraphs, sets language per paragraph, and replaces any existing tags, which makes it most useful on untagged PDFs or PDFs with poor tags. An optional report in XLSX format lists replaced tags, new tags, and content that needs review, and a shiftHeadings option changes how heading levels are assigned.

The how-to page(opens in a new tab) documents the /operation/autotag endpoint and its limits: files up to 100 MB, non-scanned PDFs up to 200 pages, scanned PDFs up to 100 pages, OCR configured for English, and a request rate below 25 per minute. Adobe states that the output may not comply with WCAG or PDF/UA and that alt text and complex tables need review. A separate Accessibility Checker API(opens in a new tab) reports on the machine-verifiable requirements of PDF/UA and WCAG over a page range. SDKs cover Java, .NET, Node.js, and Python, and the free tier(opens in a new tab) includes 500 document transactions a month across PDF Services.

3. PDFix SDK

PDFix(opens in a new tab) documents an auto-tag SDK that builds a complete logical tag tree: headings and paragraphs, lists and complex tables, forms, sections, figures, and nested elements. It offers four approaches: no template, a preflight-generated template, an AI-generated template, and a predefined JSON template. The SDK page(opens in a new tab) lists Docling and Paddle as local AI engines and Amazon Textract and OpenAI as cloud engines, plus a built-in veraPDF validator with JSON or XML output for continuous integration. AI-generated alt text is available as an action. The SDK runs on Windows, macOS, and Linux with Python, Java, C++, .NET, and JavaScript bindings, and pricing(opens in a new tab) is quote-based per instance, with a free tier and a separate managed remediation service.

4. Apryse SDK

Apryse(opens in a new tab) documents PDF/UA-1 conversion in its server and desktop SDK: The conversion tags the document, embeds fonts, and updates metadata for ISO 14289-1. Apryse states that auto-tagging requires extractable text and that scanned or image-only PDFs produce malformed files, so OCR has to come first. Production use requires the Accessibility package and the Data Extraction module, and trial output is capped at 100 pages with an evaluation page inserted. The conversion page doesn’t describe a validation step, so plan a separate validator.

5. Foxit PDF SDK

Foxit PDF SDK(opens in a new tab) supports auto-tagging from version 8.4 with a license key that includes the Accessibility module, and from version 12.0 it improves recognition of heading levels. Its developer guide lists TaggedPDF for tagging, AccessibilityChecker for checks, AccessibilityFixer for fixes such as document title and tab order, and TagTreeEditor for tag properties. Bindings include C, C++, Java, C#, Python, Node.js, and Go. Foxit’s accessibility page(opens in a new tab) describes PDF/UA-1 checks and repairs in Foxit PDF Editor and batch Autotag through its Enterprise Automation services.

6. axes4 axesFlip

axesFlip(opens in a new tab) is axes4’s engine for large volumes of recurring documents such as account statements. You build a template in axesFlip Designer, and the engine applies it to every document of that type. It runs on the customer’s servers, from the command line, or through an SDK, and axes4 states that it processes 100 to 200 pages per second. Validation isn’t included. axes4 points to its axesPAC API for automated checks and to the axesPDF(opens in a new tab) desktop editor for manual fixes.

7. Equidox AI

Equidox AI(opens in a new tab) is a fully automated option for high-volume templated documents. Equidox says machine learning and computer vision models tag the PDF elements, deployment can be on premises or in the cloud, and access comes through an API, an on-demand user interface, or a managed service. Equidox states that output meets WCAG 2.1 and Section 508. Pricing isn’t published.

8. Allyant CommonLook PDF

Allyant CommonLook PDF(opens in a new tab) is a remediation editor available in the browser or on the desktop. Its AI-driven tagging supports tables, lists, forms, and other elements, it supports PDF/UA, WCAG, and HHS standards, and each remediated file comes with a downloadable validation report. The product page doesn’t document a public API, so it fits specialist remediation rather than backend pipelines.

Validate with veraPDF and PAC

Validation is a separate step from tagging, whichever tool produced the file. veraPDF(opens in a new tab) is an open source validator covering all PDF/A and PDF/UA parts and conformance levels; it’s behind Nutrient’s benchmark and PDFix’s built-in checks. PAC(opens in a new tab) (PDF Accessibility Checker) is a free desktop checker for PDF/UA and WCAG that reports rather than fixes. Machine checks cover only part of PDF/UA, so screen reader testing still closes the loop. The PDF/UA validation post explains where validation fits.

Scenario-based recommendations

• Choose Nutrient when backend jobs need PDF/UA-1 auto-tagging at volume from a hosted API, with the option to self-host through Nutrient SDKs or Document Engine.
• Choose Adobe PDF Accessibility Auto-Tag API when Adobe PDF Services is already the platform and an Excel tagging report suits your review process.
• Choose PDFix SDK when tagging must stay on premises and layout templates or local AI engines suit your document mix.
• Choose Apryse SDK when Apryse is already the document engine and your inputs have extractable text.
• Choose Foxit PDF SDK when tagging, accessibility checks, and tag-tree edits should share one native SDK.
• Choose axes4 axesFlip when thousands of statements share a layout that one template can describe.
• Choose Equidox AI when templated documents should be remediated through an API or a managed service.
• Choose Allyant CommonLook PDF when accessibility specialists remediate documents one at a time in an editor.

Run a fair proof of concept

Your documents decide the result.

1. Collect 30–50 representative PDFs: multicolumn reports, forms, scans, long tables, and charts.
2. Run each candidate, and then run every output through the same validator, such as veraPDF.
3. Record pass rates and failure types per document class.
4. Test the output with a screen reader. Check heading navigation, table reading, reading order, and figure descriptions.
5. Time a batch and confirm documented limits, retries, and error responses.
6. Model the monthly cost in pages and validations, plus the human review time that remains.

Start with the free plan of the Nutrient DWS Accessibility API, which includes 20 auto-tagged pages and 100 validations a month, and send the same files through each candidate.

FAQ

Related reading

• PDF accessibility SDK: WCAG 2.2, Section 508, and PDF/UA
• PDF/UA compliance guide: Requirements, standards, and best practices
• PDF/UA validation in Java, Python, .NET SDKs, and a PDF server
• Nutrient DWS Accessibility API