PDF/UA conversion API

Use Nutrient to move Word, Excel, PowerPoint, HTML, scanned images, and existing PDFs into accessible PDF workflows. Combine conversion, OCR, auto-tagging, and review steps in one platform instead of stitching together separate tools.


ACCESSIBILITY OUTPUT

Build conversion pipelines around the details that matter for PDF/UA

Auto-tagging and structure

Generate headings, paragraphs, lists, and semantic structure instead of shipping flat visual output.

Reading order and tables

Preserve logical flow, identify tabular content, and reduce the hand-fixing needed after conversion.

Forms and interactive content

Carry accessibility work into form-heavy PDFs so output remains usable in regulated workflows.

Validation-oriented workflow

Support teams working toward PDF/UA, Section 508, ADA programs, and WCAG-aligned delivery requirements.

IMPLEMENTATION

One API call can turn conversion into a compliance workflow

Use DWS Processor API for the server-side build step, Document Engine when you control generation pipelines, and Web SDK when reviewers need to inspect accessible output in the browser.

Terminal window
curl -X POST https://api.nutrient.io/build \
-H "Authorization: Bearer YOUR_API_KEY" \
-F 'document=@sample.docx' \
-F 'instructions={
"parts": [{ "file": "document" }],
"output": {
"type": "pdfua",
"ocr": true,
"tagging": {
"headings": true,
"tables": true,
"forms": true,
"readingOrder": "auto"
}
}
}' \
--fail \
-o accessible-output.pdf

PRODUCT MAPPING

Choose the layer that matches your bottleneck

Some teams need batch remediation. Others need HTML-to-PDF generation, browser review, or a broader accessibility program. Nutrient lets you start with one layer and expand without replacing the stack.

Questions teams ask before they commit to PDF/UA conversion

What inputs can I convert into PDF/UA workflows?
Nutrient supports the common starting points teams bring into accessibility programs: Office files, controlled HTML, image-based inputs that need OCR, and existing PDFs that need remediation.
Is PDF/UA conversion the same as WCAG compliance?
No. PDF/UA addresses document structure and accessibility inside the PDF itself. WCAG applies to the full digital experience, which is why many teams pair PDF/UA output with accessible browser delivery and review.
Do I still need review and validation after conversion?
Usually, yes. Automation removes repetitive remediation work, but teams still need QA, validation, and exception handling for complex layouts, charts, or poorly structured source files.
Where should I start if I have both viewing and conversion needs?
Start with the PDF accessibility hub for the cross-product path, and then move into the API, SDK, or guide that matches your workflow.

NEXT STEP

Move from conversion evaluation to rollout planning

Use the API page for implementation detail, the checklist for QA handoff, and a demo when you want help mapping PDF/UA conversion to your source systems and document volume.