---
title: "PDF SDK benchmark (2026): Rendering, PDF/A, PDF/UA, OCR, and React Native compared"
canonical_url: "https://www.nutrient.io/blog/pdf-sdk-performance-benchmark/"
md_url: "https://www.nutrient.io/blog/pdf-sdk-performance-benchmark.md"
last_updated: "2026-06-02T22:02:09.313Z"
description: "2026 PDF SDK benchmark results across rendering speed, PDF/A conformance, PDF/UA accessibility, and OCR — covering Nutrient, Apryse, IronPDF, Foxit, PDF-Tools AG, Aspose, Syncfusion, and PDFix. 3,157 documents tested."
---

Every pipeline that processes documents has a PDF SDK at its foundation. Before a compliance system can archive a contract, before an accessibility checker can validate a form, and before a web app can serve a document to a returning user, the SDK has to render, convert, and extract from that file correctly — not approximately, but correctly enough for automated systems to act on.

We ran standardized benchmarks across rendering, PDF/A conversion, PDF/UA accessibility tagging, and optical character recognition (OCR) — across 3,157 documents and 22 rendering scenarios.

See the full [benchmark reports and methodology](https://www.nutrient.io/sdk/benchmarks/) for the complete data behind this post.

**TL;DR**

- **Fastest first-page render** — Nutrient Server is fastest on both cold and warm start. Nutrient WASM wins cold start on all 22 documents against Apryse WASM on Wi-Fi. On zoom interactions, WASM viewers outperform server-rendered tiles.

- **Best PDF/A accuracy** — Nutrient leads at 97.2 percent veraPDF pass rate, versus 85.3 percent for Apryse and 41.1 percent for IronPDF.

- **Best PDF/UA accuracy** — Nutrient leads at 96.5 percent, nearly 32 points ahead of Apryse (64.6 percent).

- **OCR throughput** — Nutrient Document Engine is 9.3× faster than Apryse on simple PDFs; Apryse times out on medium PDFs that Nutrient completes in 20 seconds.

- **React Native** — New Architecture cuts component load time by 20–32 percent on both iOS and Android.

- **Zero critical failures** — Nutrient recorded zero critical failures across 3,157 files in both PDF/A and PDF/UA runs.

## What vendor benchmarks miss

PDF SDK marketing pages list the same capabilities. Vendors claim speed, accuracy, and compliance — and the numbers they publish aren’t false. They just don’t measure what downstream systems actually need.

The critical gap is between nominal success rates and output correctness. A process that completes without errors isn’t the same as a process that produces a conformant file. IronPDF converts 99.3 percent of files without raising an error, but only 41.1 percent of its output passes veraPDF conformance. If your archival system ingests those files, it silently stores invalid documents — 59 percent of the total — with no pipeline error to catch it. Your compliance audit will find them later.

The same pattern applies to rendering: A viewer that displays something onscreen isn’t the same as one that renders it reliably enough for automated extraction.

We measure output correctness: veraPDF conformance, rendering accuracy under realistic network conditions, and throughput at scale — not just whether processes complete. Tests were run between December 2025 and April 2026.

## Test methodology

Each benchmark uses a consistent methodology, with the complete reports and data on the [PDF SDK benchmarks](https://www.nutrient.io/sdk/benchmarks/) page:

- **Web rendering** — Playwright headless Chromium, `performance.now()` API, mean of 10 runs per document, 30 Mbps down/15 Mbps up/2ms RTT Wi-Fi throttle, Brotli-compressed viewer assets, 22 documents across six categories. Test date: 24 April 2026.

- **PDF/A and PDF/UA conversion** — 3,157 files per vendor, veraPDF conformance validation, throughput in files/minute, and reliability tracked via critical failures and bottlenecks. Test date: 13 March 2026.

- **React Native** — 15 runs per platform on iPhone 17 Simulator (iOS 26.1) and Pixel 9 (Android API 35), comparing Nutrient’s legacy bridge vs. the New Architecture, and Nutrient vs. Apryse. Test date: December 2025.

- **OCR** — Nutrient Document Engine 1.15 vs. Apryse 11.11.1 on AWS c7i.4xlarge (Intel x86_64, 16 vCPU, 32 GiB RAM), measured as direct SDK call timings to keep the comparison fair. Test date: April 2026.

- **Winner threshold for rendering** — Greater than 5 percent difference. Below that, results are treated as a tie.

## Web SDK rendering benchmark

We benchmarked [Nutrient Web SDK](https://www.nutrient.io/sdk/web/) in both server-rendered and standalone WASM modes against Apryse WASM.

### Cold start (first visit)

Cold start measures time from navigation to first page render, including asset loading, WASM initialization, document parse, and first-page render. The user has never visited before and nothing is cached.

**Nutrient Server** renders all 22 documents in **936ms–1.14s**. Its server-rendered architecture means the browser receives a prerendered page, with minimal client-side work.

**Nutrient WASM** beats Apryse WASM on all 22 documents. Brotli-compressed assets reduce the initial transfer size.

#### Cold start results — Selected documents

| Document type       | Nutrient Server | Nutrient WASM | Apryse WASM |
| ------------------- | --------------- | ------------- | ----------- |
| Simple text         | **958ms**       | **2.02s**     | 2.98s       |
| With images         | **1,000ms**     | **2.08s**     | 3.05s       |
| With annotations    | **1,070ms**     | **2.17s**     | 3.12s       |
| Text-heavy          | **1,070ms**     | **2.82s**     | 3.74s       |
| Mixed content       | **1,000ms**     | **3.08s**     | 4.01s       |
| Interactive form    | **994ms**       | **2.13s**     | 5.17s       |
| Heavily annotated   | **1,060ms**     | **2.45s**     | 3.41s       |
| CAD drawing         | **986ms**       | **2.04s**     | 3.00s       |
| Electrical report   | **1,020ms**     | **2.40s**     | 5.45s       |
| Scanned document    | **936ms**       | **8.71s**     | 9.53s       |
| Linearized (remote) | **1,050ms**     | **5.18s**     | 6.88s       |

Interactive forms show the sharpest gap: Apryse WASM is 2.4× slower than Nutrient WASM on cold start — an overhead that compounds across every form load in a session.

### Warm start (return visit)

Warm start reuses browser context but creates a fresh page per run. Viewer assets are cached; the PDF is fetched again. This reflects the most common scenario for returning users.

Nutrient WASM wins on 19 of 22 documents. Apryse WASM wins on 0, with 3 ties. The interactive form gap is notable here too — Apryse is 2× slower than Nutrient WASM on warm start (830ms vs. 406ms).

#### Warm start results — Selected documents

| Document type       | Nutrient Server | Nutrient WASM | Apryse WASM |
| ------------------- | --------------- | ------------- | ----------- |
| Simple text         | **227ms**       | **311ms**     | 494ms       |
| With annotations    | **262ms**       | **431ms**     | 568ms       |
| Interactive form    | **276ms**       | **406ms**     | 830ms       |
| Image-heavy         | **240ms**       | **1.69s**     | 1.86s       |
| Electrical report   | **247ms**       | **689ms**     | 1.03s       |
| Linearized (remote) | **302ms**       | **1.93s**     | 2.87s       |

For linearized remote PDFs — common in document sharing workflows — Nutrient WASM is 1.5× faster on warm start.

### Memory usage

We measured JavaScript (JS) heap usage during rendering. Lower is better for scaling concurrent users.

Nutrient Server consistently has the lowest JS heap across all 22 documents (37.8–61.0 MB). For WASM viewers, results vary by document type — Apryse uses less heap on 10 documents, Nutrient WASM on 9, with 3 ties. Nutrient WASM’s heap advantage appears on complex documents: For a scanned document, Nutrient WASM uses 51.0 MB versus Apryse WASM’s 98.2 MB.

### Zoom render

Zoom render measures how quickly the viewer reports a rerender after zooming to 3× magnification. WASM viewers render zoom client-side; Nutrient Server fetches server-rendered tiles for the same interaction, adding roundtrip latency.

Across 22 documents, Nutrient WASM wins 12 and Apryse WASM wins 6, with 4 ties. The pattern differs from first-page render: Nutrient WASM’s advantage typically concentrates on complex and content-heavy documents, while Apryse WASM is faster on simpler ones.

#### Zoom render results — Selected documents

| Document type    | Nutrient Server | Nutrient WASM | Apryse WASM |
| ---------------- | --------------- | ------------- | ----------- |
| Image-heavy      | 380ms           | **71ms**      | 192ms       |
| With annotations | 231ms           | **55ms**      | 107ms       |
| Text-heavy       | 91ms            | **41ms**      | 61ms        |
| Magazine         | 425ms           | 112ms         | **67ms**    |
| Simple text      | 154ms           | 40ms          | **38ms**    |
| With images      | 213ms           | 53ms          | **46ms**    |
| Interactive form | 228ms           | 45ms          | **41ms**    |

On complex content, Nutrient WASM is up to 2.7× faster. The split reflects each engine’s architecture: Nutrient WASM is stronger where content complexity dominates; Apryse WASM is faster on lightweight documents.

## React Native benchmark

[Nutrient React Native SDK](https://www.nutrient.io/sdk/react-native/) performance was measured across 15 runs per platform on iPhone 17 Simulator (iOS 26.1) and Pixel 9 (Android API 35) in December 2025.

### New Architecture vs. legacy bridge

Nutrient React Native SDK supports both the legacy bridge and the New Architecture (JSI/Bridgeless Mode introduced in React Native 0.74+). The New Architecture eliminates serialization overhead between JavaScript and native layers.

| Metric                      | Old architecture | New Architecture | Improvement    |
| --------------------------- | ---------------- | ---------------- | -------------- |
| iOS component mount         | 52ms             | 35ms             | **32% faster** |
| Android component mount     | 87ms             | 69ms             | **20% faster** |
| Android `SelectAnnotations` | 16.5ms           | 1.73ms           | **90% faster** |

The Android `SelectAnnotations` result is particularly significant: a 90 percent reduction in annotation selection latency, achieved by removing bridge serialization on a frequently triggered user interaction.

### Nutrient vs. Apryse on React Native

| Metric                     | Nutrient (New Architecture) | Apryse | Platform |
| -------------------------- | --------------------------- | ------ | -------- |
| Component initialization   | **35ms**                    | 58ms   | iOS      |
| Component initialization   | **69ms**                    | 103ms  | Android  |
| Document load (simple PDF) | **120ms**                   | 187ms  | iOS      |
| Document load (simple PDF) | **198ms**                   | 264ms  | Android  |

One measurement caveat: Apryse’s flatten and save operations return immediately after scheduling the task rather than waiting for completion. Direct throughput comparisons on write operations should account for this architectural difference.

## PDF/A conversion benchmark

PDF/A is the ISO standard for long-term document archiving. When a conversion pipeline produces a non-conformant file, it often looks fine onscreen — but it fails automated validation, which means your archival system stores a file that auditors will reject. A file can convert without errors yet still fail veraPDF conformance checks: You need veraPDF validation to tell the difference.

We processed **3,157 files per vendor** and validated every output with veraPDF.

### veraPDF conformance

| Vendor                       | veraPDF pass rate | Overall valid rate |
| ---------------------------- | ----------------- | ------------------ |
| **Nutrient (GdPicture.NET)** | **97.2%**         | **95.4%**          |
| PDF-Tools AG                 | 96.7%             | 94.0%              |
| Apryse (PDFTron)             | 85.3%             | 84.4%              |
| Foxit PDF SDK                | 78.1%             | 72.8%              |
| Aspose.PDF                   | 73.8%             | 67.8%              |
| IronPDF                      | 41.1%             | 40.8%              |
| Syncfusion PDF               | 0.6%              | 0.5%               |

Nutrient leads at 97.2 percent — narrowly ahead of PDF-Tools AG and nearly 12 points ahead of Apryse. IronPDF and Syncfusion fail validation on the majority of their output: the exact failure mode that compliance workflows need to catch before it reaches an archive.

### Reliability and throughput

| Vendor       | Success rate | Critical failures | Throughput (files/minute) |
| ------------ | ------------ | ----------------- | ------------------------- |
| **Nutrient** | **98.2%**    | **0**             | **1,753**                 |
| Apryse       | 98.9%        | 1                 | 1,839                     |
| IronPDF      | 99.3%        | 11                | 701                       |
| PDF-Tools AG | 97.2%        | 2                 | 648                       |
| Foxit        | 93.2%        | 11                | 91                        |
| Aspose       | 91.8%        | 19                | 77                        |
| Syncfusion   | 92.4%        | 12                | 39                        |

Nutrient’s zero critical failures are the most important signal here. A critical failure — process crash, stack overflow, or memory corruption — halts the conversion loop entirely. Every other vendor in this table had at least one. In production, that means a pipeline stoppage requiring manual intervention.

Apryse edges Nutrient on throughput — but speed matters less than conformance in archival workflows. A faster pipeline that produces non-conformant files isn’t faster; it’s just wrong faster.

### Output file size

Smaller output files reduce archival storage and transfer costs. Nutrient produces the smallest average output across all vendors tested.

| Vendor       | Average output size |
| ------------ | ------------------- |
| **Nutrient** | **1.06 MB**         |
| PDF-Tools AG | 1.15 MB             |
| Foxit        | 1.41 MB             |
| Apryse       | 1.48 MB             |
| Syncfusion   | 1.49 MB             |
| IronPDF      | 2.10 MB             |
| Aspose       | 2.42 MB             |

Nutrient’s files are 28 percent smaller than Apryse and half the size of IronPDF — a meaningful cost difference at archival scale.

Nutrient’s PDF/A throughput has improved by 255 percent since November 2025 (492 → 1,753 files/minute), with veraPDF pass rate improving by 5.1 points in the same period.

## PDF/UA accessibility benchmark

PDF/UA is the ISO standard for accessible PDFs — required in regulated industries and increasingly mandated by accessibility laws. A non-conformant file means a screen reader cannot navigate it reliably, which blocks users who depend on assistive technology and exposes your organization to compliance risk under WCAG 2.1 or Section 508. The same veraPDF methodology applies.

### veraPDF conformance

| Vendor                       | veraPDF pass rate | Critical failures | Throughput (files/minute) |
| ---------------------------- | ----------------- | ----------------- | ------------------------- |
| **Nutrient (GdPicture.NET)** | **96.5%**         | **0**             | **322**                   |
| Apryse (PDFTron)             | 64.6%             | 7                 | 49                        |
| IronPDF                      | 47.9%             | 27                | 92                        |
| PDFix SDK                    | 15.5%             | 8                 | 65                        |

Nutrient leads by a large margin — nearly 32 points ahead of Apryse. For organizations subject to WCAG 2.1 or Section 508, that gap translates to roughly 1,000 additional non-conformant files per 3,000 processed — documents that screen readers cannot navigate reliably.

Nutrient is also the fastest in this benchmark — 6.6× faster than Apryse.

Nutrient’s PDF/UA veraPDF pass rate improved by 12.6 points since November 2025 (83.9 percent → 96.5 percent). Bottlenecks greater than one minute fell from 113 to 23; critical bottlenecks greater than five minutes from 25 to 3. Critical failures remained at zero.

## OCR benchmark

[Nutrient Document Engine](https://www.nutrient.io/sdk/document-engine/) includes OCR for converting scanned documents into searchable, text-extractable PDFs. We compared Document Engine 1.15 against Apryse 11.11.1 on AWS c7i.4xlarge, measured as direct SDK call timings on the same input files.

| Document complexity | Nutrient Document Engine | Apryse          | Result                     |
| ------------------- | ------------------------ | --------------- | -------------------------- |
| Simple              | **1.9s**                 | 17.6s           | **9.3× faster**            |
| Medium              | **20.2s**                | timed out (90s) | **Apryse didn’t complete** |
| Complex             | **4.8s**                 | 15.7s           | **3.3× faster**            |

The medium-document case is the operational difference. A single document that exceeds an OCR pipeline’s timeout halts the loop and requires manual recovery. Nutrient completes the same document in 20 seconds, which means OCR jobs run to completion on documents that would otherwise need to be requeued or processed by a fallback path.

## Key findings

Three patterns emerged across the benchmarks:

**Server rendering bypasses the cold-start problem entirely.** Nutrient Server renders all 22 documents in 936ms–1.14s on Wi-Fi. No WASM-based viewer from any vendor comes close, because server-rendered delivery sends a prerendered page — the browser does no asset loading, WASM initialization, or document parsing before first paint. If first-visit speed is a requirement, architecture is the answer, not SDK tuning.

**Nutrient WASM wins cold and warm start on Wi-Fi.** Nutrient WASM beats Apryse WASM on all 22 cold-start documents and on 19 of 22 warm-start documents, with the rest tied. Brotli-compressed asset delivery is the largest contributor on cold start; warm start reflects engine performance once assets are cached.

**Nominal success rates hide conformance failures — and those failures are silent.** Multiple SDKs report conversion success rates above 90 percent while producing output that fails veraPDF validation on a substantial share of files. A file that converts without an error but fails veraPDF enters your archival system invisibly — no pipeline exception, no alert. Nutrient’s 97.2 percent PDF/A and 96.5 percent PDF/UA pass rates, with zero critical failures across 3,157 files, are the highest tested.

**OCR throughput matters less than OCR completion.** A pipeline that times out on medium-complexity documents creates downstream work even when the average runtime looks competitive. Nutrient Document Engine completed every category in the OCR test set; Apryse exceeded the 90-second timeout on medium documents Nutrient finished in 20 seconds.

## Choosing the right PDF SDK

| Use case                                     | Recommended Nutrient product                                    |
| -------------------------------------------- | --------------------------------------------------------------- |
| Web viewer, first-visit performance priority | [Nutrient Web SDK](https://www.nutrient.io/sdk/web/) in server-rendered mode             |
| Web viewer, standalone WASM deployment       | [Nutrient Web SDK](https://www.nutrient.io/sdk/web/) in WASM mode                        |
| PDF/A archiving for compliance workflows     | [Nutrient Document Engine](https://www.nutrient.io/sdk/document-engine/)                     |
| PDF/UA for accessibility requirements        | [Nutrient Document Engine](https://www.nutrient.io/sdk/document-engine/)                     |
| OCR on scanned document pipelines            | [Nutrient Document Engine](https://www.nutrient.io/sdk/document-engine/)                     |
| React Native document apps                   | [Nutrient React Native SDK](https://www.nutrient.io/sdk/react-native/) with New Architecture |

## FAQ

#### What is veraPDF and why does it matter for PDF/A benchmarks?

veraPDF is the industry-standard open source validator for PDF/A and PDF/UA conformance, developed with the support of the PDF Association. A file can “convert successfully” — meaning the process completes without an error — but still fail veraPDF validation because the output doesn’t meet the ISO standard. High nominal success rates combined with low veraPDF pass rates (like IronPDF’s 99.3 percent success/41.1 percent veraPDF) indicate the SDK is producing non-conformant files.

#### What is the difference between Nutrient WASM and Nutrient Server?

Nutrient WASM runs the PDF engine in the browser using WebAssembly — no server required for rendering. Nutrient Server prerenders pages on the server and streams them to the client, resulting in faster cold starts (936ms–1.14s on Wi-Fi) and lower JS heap usage. For applications where first-paint speed is critical, Server mode is the fastest option. For offline-capable or privacy-sensitive applications, WASM is the better fit.

#### What does a critical failure mean in the conversion benchmarks?

A critical failure is an unrecoverable error during batch processing — typically a process crash, stack overflow, or memory corruption — that aborts the conversion loop and requires manual intervention. In production pipelines, critical failures create SLA risk and require operational overhead to detect and recover from. Nutrient recorded zero critical failures across 3,157 files in both the PDF/A and PDF/UA benchmark runs.

#### How were the web rendering benchmarks measured?

We used Playwright headless Chromium with `performance.now()` timing. Each document was run 10 times. Cold start uses a fresh browser context and fresh page per run. Warm start reuses the browser context but creates a fresh page per run, with the PDF URL cache-busted so the document is fetched again while viewer assets stay cached. All viewer JS, CSS, and WASM assets were served with Brotli compression to match production CDN delivery.

#### Which Nutrient product fits which workflow?

For web rendering, Nutrient Web SDK runs in either server-rendered mode (fastest first-page render) or standalone WASM mode (no backend required). For PDF/A or PDF/UA conversion and OCR pipelines, Nutrient Document Engine is the right fit — 97.2 percent PDF/A and 96.5 percent PDF/UA veraPDF pass rates with zero critical failures across 3,157 files, and 9.3× faster OCR than Apryse on simple PDFs. For mobile document apps, Nutrient React Native SDK with New Architecture delivers 20–32 percent faster component load on iOS and Android.

#### How was the OCR benchmark measured?

Nutrient Document Engine 1.15 and Apryse 11.11.1 were run on the same AWS c7i.4xlarge instance (Intel x86_64, 16 vCPU, 32 GiB RAM) against the same input documents. Each SDK is measured via direct SDK calls — for Document Engine, server-side trace timings from request body sent to response first byte; for Apryse, direct SDK calls. This removes the HTTP roundtrip latency that would otherwise penalize Document Engine in a head-to-head with a library-only SDK. Apryse’s OCR run on medium-complexity documents exceeded the 90-second per-document timeout and didn’t produce a result.

#### What is the React Native New Architecture and does it affect PDF rendering?

The React Native New Architecture (JSI/Bridgeless Mode) removes the serialization bridge between JavaScript and native code. For PDF SDKs, this reduces latency on any operation that crosses the JS-native boundary — including component mounting, annotation interactions, and document load. Nutrient React Native SDK supports New Architecture in full. Benchmarks show 20–32 percent faster component mount times on iOS and Android, and up to 90 percent faster annotation selection on Android (16.5ms → 1.73ms).

Explore the full [benchmark reports](https://www.nutrient.io/sdk/benchmarks/), or [try Nutrient for free](https://www.nutrient.io/sdk/) — it includes [Web SDK](https://www.nutrient.io/sdk/web/), [Document Engine](https://www.nutrient.io/sdk/document-engine/), and API access.

## Related reading

- [PDF SDK benchmarks](https://www.nutrient.io/sdk/benchmarks/)

- [Nutrient Web SDK](https://www.nutrient.io/sdk/web/)

- [Nutrient React Native SDK](https://www.nutrient.io/sdk/react-native/)

- [Nutrient Document Engine](https://www.nutrient.io/sdk/document-engine/)
---

## Related pages

- [The business case for accessibility: Five ways it drives enterprise value](/blog/5-ways-accessibility-drives-enterprise-value.md)
- [Advanced Techniques For React Native Ui Components](/blog/advanced-techniques-for-react-native-ui-components.md)
- [Best Document Viewers](/blog/best-document-viewers.md)
- [The CEO’s AI playbook: Why decision architecture beats model selection](/blog/ceo-ai-playbook-decision-architecture.md)
- [The CTO’s AI playbook: Why accountability architecture beats orchestration](/blog/cto-ai-playbook-accountability-architecture.md)
- [Digital Signatures](/blog/digital-signatures.md)
- [Complete Guide To Pdfjs](/blog/complete-guide-to-pdfjs.md)
- [Document Ai Vs Ocr](/blog/document-ai-vs-ocr.md)
- [Document Viewer](/blog/document-viewer.md)
- [How To Build A Reactjs Viewer With Pdfjs](/blog/how-to-build-a-reactjs-viewer-with-pdfjs.md)
- [or](/blog/how-to-build-a-javascript-pdf-viewer-with-pdfjs.md)
- [base_url tells WeasyPrint where to resolve relative asset paths](/blog/how-to-generate-pdf-reports-from-html-in-python.md)
- [or](/blog/how-to-build-a-reactjs-pdf-viewer-with-react-pdf.md)
- [Nutrient Vs Conga Composer](/blog/nutrient-vs-conga-composer.md)
- [Linearized Pdf](/blog/linearized-pdf.md)
- [Pdf Page Labels](/blog/pdf-page-labels.md)
- [Pdf Sdk Compliance Security Checklist](/blog/pdf-sdk-compliance-security-checklist.md)
- [Online Document Viewer](/blog/online-document-viewer.md)
- [Process Flows](/blog/process-flows.md)
- [Pdfjs Limitations Commercial Upgrade](/blog/pdfjs-limitations-commercial-upgrade.md)
- [or](/blog/sample-blog-updated.md)
- [What Are Annotations](/blog/what-are-annotations.md)
- [Vector Pdf](/blog/vector-pdf.md)
- [Convert an HTML file to PDF.](/blog/top-ten-ways-to-convert-html-to-pdf.md)
- [Why Your Ai Agent Hallucinates Pdf Table Data](/blog/why-your-ai-agent-hallucinates-pdf-table-data.md)
- [What Is A Vpat](/blog/what-is-a-vpat.md)