PDF Text Extraction Research: July 2026 Results

Inspect 15 synthetic fixture/template comparisons, original PDFs and extracted text, scoring definitions and the limits of a historical engine comparison.

Published 7 October 2026 · Nodesify · Commentary updated 11 October 2026

What does this dataset show?

It records text extracted from three synthetic resumes rendered through five layouts using two PDF engines in July 2026: 15 combinations and 30 PDFs. It offers inspectable examples of preserved and missing text. These are historical local extraction measurements, not ATS acceptance rates, hiring outcomes or verification of the current release.

The original JSON timestamp is 2026-07-04T17:19:41.466Z; the accompanying narrative is dated 5 July. This publication repackages retained artifacts. No benchmark was rerun for it.

Download the evidence

Complete dataset ZIP: original PDFs, extracted text, shared HTML inputs, results and recovered source.
Original raw JSON report and per-case CSV.
Recovered fixture source, scoring source and rendering source snapshot.
Dataset README, reproduction steps and limitations and SHA-256 file checksums.

The resumes are synthetic. Their named employers, credentials, achievements and links are illustrative, with no endorsement or verified employment implied. Replace all fictional details before using any sample in an application.

A worked example: skill names lose their separators

In the retained standard Professional-template case, these exact extracted lines show different spacing between the same four skill names. Both lines come from the July artifacts; this is not a new run or a comparison of current engine versions.

Chromium extraction

Languages: TypeScript      Go    Python      Rust

WeasyPrint extraction

Languages:TypeScriptGoPythonRust

The second line joins the skill names together. The observation concerns word boundaries in this extraction path; it does not demonstrate an employer rejecting a resume. Inspect the original Chromium text, WeasyPrint text, Chromium PDF and WeasyPrint PDF.

For your own document, try ordinary text separators or a simpler layout, export again and compare the actual downloaded text. That is a suggested remedy to check, not a measured fix in this dataset. Follow the worked export checklist and inspect the employer’s populated fields where available.

Which versions and inputs were used?

The historical narrative identifies Chrome for Testing 149.0.7827.55 and WeasyPrint 63.0. Chromium PDF metadata identifies Skia/PDF m149. The original Poppler version, operating-system package versions and container digest are not recorded in the raw report.

The standard fixture is an ASCII engineering resume; the Unicode fixture contains accented names and selected punctuation; the long fixture exercises multiple pages and a marked bullet. Both engines received the same archived HTML for each combination. Font substitution and engine layout behavior can still affect the comparison.

Fixture and scoring source was recovered from the retained 5 July repository snapshot 10e4d4e5594b80afa4a70381409a64a54c39d194. It contains the engineering fixture visible in these artifacts. The exact generating revision was not recorded. Later repository fixtures changed, so current source should not be substituted for the recovered fixture.

What exactly was scored?

The scorer collapses whitespace and page-break characters and removes soft hyphens and selected invisible characters before matching. A matched phrase therefore does not establish its original visual placement. The implementation, rather than a stronger description in a source comment, defines each check.

Word integrity: Matched unique words from selected fields / expected unique words, after lowercasing and edge-punctuation removal. Words shorter than two characters are excluded.
Section titles: Case-insensitive substring matches for seven shared headings. This does not check section order or whether fields belong to the correct section.
Contact information: Expected email, normalized phone digits and visible link labels. The implementation does not verify hyperlink destinations or a vendor’s field extraction.
Key tokens: Selected names, companies, education, skills and years, using normalized phrases or word-boundary matches. It does not verify credentials or semantic meaning.
Unicode preservation: Nine selected Unicode tokens in the Unicode fixture. This is not coverage of all scripts and characters.
Marker and opening phrase: Long fixture only: 0 if its marker is missing, 1 if the expected opening phrase appears within the first 100 normalized characters after it, otherwise 0.5. This does not prove the whole bullet or every page boundary is intact.

The raw report’s contact description refers to URLs, but the code checks visible link labels. Its cross-page description suggests full continuity, but the implemented check tests the marker and opening phrase. Neither check reproduces a commercial ATS parser.

Per-metric averages from the raw cases

Arithmetic means; 15 cases for the first four metrics and five cases for each fixture-specific metric.
Metric	Cases	Chromium	WeasyPrint
Word integrity	15	99.6%	91.3%
Section titles	15	100.0%	100.0%
Contact information	15	94.4%	94.4%
Key tokens	15	99.4%	79.6%
Unicode preservation	5	100.0%	100.0%
Marker and opening phrase	5	100.0%	100.0%

These means are calculated from the preserved raw rows. They differ from the later narrative’s word, contact and key-token averages. The report’s summary averages of 98.6% and 92.6% combine all 70 metric observations; they are not word-integrity averages. The original files remain unchanged, and this discrepancy is disclosed rather than silently corrected.

Results for every fixture and layout

Each table shows scores from the original JSON, rounded to one decimal place for display. Raw fractions and missing-token details remain available in JSON and CSV. A score of 100% means the defined check matched, not that every property of the document is correct.