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.

EXPLORE PDF/UA API GET CHECKLIST

SUPPORTED FLOWS

Capture the messy cases that usually break accessible PDF delivery

Most accessibility programs inherit mixed document sources. Nutrient supports the common conversion paths teams need when PDF/UA becomes a hard requirement instead of a manual afterthought.

PDF/UA conversion workflow

Word to PDF/UA

Convert DOCX and templates into tagged, accessible output for contracts, notices, and generated documents.

Excel and PowerPoint to PDF/UA

Handle spreadsheet-heavy reports and presentation exports without dropping accessibility work on downstream teams.

HTML to PDF/UA

Generate accessible PDFs from controlled HTML or templated document pipelines in backend services.

Scanned files and image OCR

Layer OCR, tagging, and remediation into ingestion pipelines for image-first or legacy archives.

Existing PDF remediation

Normalize reading order, semantic tags, form fields, and structure when source files are already PDFs.

Review and delivery

Pair conversion with accessible viewing so teams can inspect output and deliver WCAG-aware browser experiences.

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.

COMPLIANCE GUIDE GET CHECKLIST 
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.

DWS Processor API

Best when conversion, OCR, and PDF/UA tagging belong in backend automation and queue-based jobs.

EXPLORE DWS PROCESSOR API

Document Engine

Best when your team owns generation pipelines and wants accessible output built closer to document creation.

EXPLORE DOCUMENT ENGINE

Accessibility hub

Best when you need the cross-product view: accessible viewing, remediation, compliance framing, and platform fit.

EXPLORE ACCESSIBILITY HUB

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.

EXPLORE PDF/UA API GET CHECKLIST