Why native PDF generation beats HTML-to-PDF
Headless-Chrome screenshots produce resumes that look right and parse wrong. Here's why we render PDFs from real text primitives instead.
Why native PDF generation beats HTML-to-PDF
The fastest way to ship a "Download PDF" button is to point headless Chrome at an HTML page and print it. It works in a demo. It quietly fails where it matters: the Applicant Tracking System.
The hidden problem with HTML-to-PDF
Tools like Puppeteer render your page, then capture it. Depending on the pipeline, you get a document whose text layer is fragile — reordered, split mid-word, or in the worst case rasterized into an image. A human sees a beautiful resume. The ATS parser sees garbage, or nothing at all.
Layout tricks that look great in a browser — multi-column flexbox, tables used for positioning, background images — are exactly what parsers choke on.
What we do instead
Perfecto renders PDFs from real text primitives: every line is a true, selectable text run, laid out in a single semantic column, top to bottom. No tables-for-layout. No images of text. Select-all and copy yields your resume in reading order — which is precisely how an ATS reads it.
It's less magic and more discipline. But "parses cleanly every time" beats "looks perfect, scores zero."