Viewer Benchmarks

What actually happens when a Chromium browser opens each sample PDF with the Foxit PDF SDK for Web vs PDF.js. Run 2026-07-24 with the same Foxit / PDF.js viewer pages linked from the file list, so you can reproduce every cell yourself.

Test environment

Client (where the viewers run)

Machine: MacBook Pro 14″ (Mac14,9)
CPU: Apple M2 Pro, 10 cores
RAM: 16 GB
Browser engine: Chromium 148 (Electron shell)
PDF.js: 4.5.136
Foxit Web SDK: 11.0

Server & network

Server: Ubuntu 24.04, Apache 2.4.58
Server CPU: Intel Core i5-4278U, 8 GB RAM
Link: Wired gigabit LAN
Measured HTTP: ~112 MB/s sustained
Range requests: Supported (Apache 206s)

Method

Each file was opened in each viewer through the same pages the file list links to. We recorded: time from navigation to the document being open (page count known), time to render page 1, time to render the last page after a direct jump (the random-access test), plus request counts and bytes transferred, cross-checked against the Apache access log on the server. PDF.js ran in its pure HTTP-Range configuration (disableAutoFetch + disableStream, 256 KB chunks). Foxit opened via openPDFByHttpRangeRequest (~131 KB chunks).

One artifact to know about: the run was automated in a background browser pane, where Chromium throttles requestAnimationFrame. PDF.js paces canvas painting on rAF, which inflated one render from ~1 s to 153 s until we switched timing to its intent: 'print' path (no rAF pacing). PDF.js render times below use that path; in a normal foreground Chrome tab we observe ~240 ms page renders on these files. Foxit rendering is not rAF-paced and needed no workaround.

Results

File	Size	Foxit PDF SDK for Web 11.0	PDF.js 4.5.136 (range mode)
sample_1gb.pdf	1.07 GB	Works Random access Open 0.74 s · page 1 ~0.33 s · jump to p576: 0.11 s · ~131 KB chunks	Works Random access Open 10.0 s · page 1 1.3 s · jump to p576: 0.36 s · 247 reqs / 61 MB to open
sample_1gb_linearized.pdf	1.07 GB	Works Random access Open 0.58–0.76 s · pages near-instant · full session (open + 2 pages): 615 reqs / 77 MB incl. idle prefetch	Works Random access Open 8.3 s · page 1 1.3 s · jump to p576: 1.2 s · 247 reqs / 61 MB to open
test_1_9gb.pdf	1.9 GiB	Works Random access Open 0.60 s · page 1 54 ms · jump to p1095: 26 ms	Works Random access Open 14.8 s · page 1 1.2 s · jump to p1095: 1.3 s · 61 MB to open
test_2_0gb.pdf	2.0 GiB	Hangs forever No transport 2 probe range reqs (482 B + 131 KB), then nothing: no download, no error event. Waited 160 s; server TX confirmed 0 MB/s	Fails fast No transport “Array buffer allocation failed” in <1 s
sample_3gb.pdf	3.2 GB	Hangs forever Same probe-then-hang class (verified on the linearized variant)	Fails fast Verified
sample_3gb_linearized.pdf	3.2 GB	Hangs forever Verified: identical 2-probe pattern in the server log, 0 bytes transferred	Fails fast Verified
sample_5gb.pdf / _linearized	5.4 GB	Hangs forever Same failure class; not separately run	Fails fast Both variants verified
sample_9gb.pdf / _linearized	9.7 GB	Hangs forever Same failure class; not separately run	Fails fast Both variants verified
sample_10gb.pdf	10.7 GB	Hangs forever Same failure class; not separately run	Fails fast Verified

“Open” = navigation to document ready (page count known). Jump times are renders of the last page after a direct jump — the proof of random access. PDF.js render times measured via its print-intent path (see Method); expect ~0.2–0.4 s in a foreground tab.

What this means

2 GiB is the wall for both JavaScript viewers — with very different failure modes

Both engines die at exactly 2³¹ bytes in Chromium-based browsers (Chrome, Edge, Brave, Electron apps), and for the same root cause: Chromium caps a single ArrayBuffer/typed array at 2 GiB, and both engines want a full-file-sized buffer once a file crosses that line. The difference is what the user sees:

PDF.js fails fast and loud — Array buffer allocation failed within a second. It pre-allocates a whole-file Uint8Array even in pure-range mode, so the size alone kills it before any real work.
Foxit hangs silently, forever — it makes two small probe range requests, abandons range streaming (its known >2 GiB behaviour), and then its fallback whole-file download never materialises: the server confirms zero bytes leave the NIC, no error event ever fires, and the UI sits on the loading state indefinitely. An earlier test of this SDK (May 2026, same finding on Foxit’s own hosted demo) observed the fallback actually downloading the entire file; in Chromium 148 it doesn’t even get that far.

Practical rule: keep web-served PDFs under 2 GiB, whatever JavaScript viewer you use. Above that, only native/desktop viewers are realistic.

Under 2 GiB, both stream well — Foxit opens an order of magnitude faster

Both do true random access. Jumping straight to the last page of a 1–1.9 GB file fetches only what's needed — neither downloads the file.
Foxit's startup is dramatically lighter: document open in 0.6–0.8 s vs PDF.js's 8–15 s. PDF.js pulls ~61 MB (247 range requests) of structure before it will even report a page count; Foxit shows the first page after a handful of ~131 KB chunks and prefetches the rest in the background (~77 MB over a full session of idle time + two page views).
Page renders: Foxit 25–330 ms; PDF.js ~1.3 s in this harness, ~0.24 s in a normal foreground tab.
Linearization made little difference on a low-latency LAN (PDF.js open: 8.3 s linearized vs 10.0 s not; Foxit sub-second either way). Its benefit shows up on high-latency links, where first-page time is dominated by round trips.

What about the browser's built-in viewer?

Not measured here — our automated harness can't instrument the native viewer (it hands PDFs to a download prompt), and the built-in viewers expose no timing or transport hooks. What can be said generally: Chrome/Edge use PDFium, Firefox ships PDF.js as its native viewer (with different memory limits than a page-embedded copy), and Safari uses PDFKit — multi-GB behaviour varies by browser and version. Use the Browser links on the file list with your own browser's task manager and network inspector to see how it copes.

Reproduce it yourself

Every number above came from the public viewer pages on this site — open the file list, pick a file, choose Foxit or PDF.js, and watch the status bar plus your browser's Network tab. The status bar reports document-open and per-page render timings live. For PDF.js render timing free of background-tab throttling, append &bench=1 to the viewer URL.