Why Resume PDFs Break in Job Portals
By Awais · · Updated
A PDF that looks right on your screen can still upload wrong. The causes are specific, and each one has a check you can run before you send the file.
Why Resume PDFs Break in Job Portals
A PDF breaks in a portal for one of four reasons: the text is not really text, the reading order is not what your eye sees, a font did not travel with the file, or the portal re-rendered the document its own way. Each has a check you can run in under a minute.
The frustrating part is that none of them are visible when you look at your own PDF. It looks fine, because your screen is showing you the drawing, not the data underneath.
A PDF holds two documents at once
This is the idea everything else follows from.
A PDF stores instructions for drawing marks in positions, and separately it stores the text those marks represent. What you see is the drawing. What an upload form reads is the text layer. Those two can disagree, and when they do, your resume looks perfect and uploads as nonsense.
So every check below is really the same check: stop looking at the drawing, and look at what the text layer says.
1. The text is not text
The most severe failure. If the resume was exported as an image, scanned from paper, or flattened by an export setting, there is no text layer at all. The portal receives a picture.
Check: open the PDF and drag to select your name. If nothing highlights, nothing can be extracted.
2. The reading order is wrong
Text is stored in an order, and that order does not have to match the visual layout. Multi-column designs are the usual cause. A parser can read the entire left column, then the entire right, so your skills list lands in the middle of a job description.
Content inside tables and content in page headers and footers cause the same problem, and headers are worse: some extractions drop that region entirely, which is how a resume arrives with no phone number.
Check: select all, copy, paste into a plain text editor. That output is close to what the portal receives. If it does not read sensibly top to bottom, neither does your application.
3. Fonts did not embed
A PDF can either carry its fonts inside the file or assume the reader has them. When it assumes, and the reader does not, something gets substituted. Substitution changes the metrics, which changes line breaks, which is how a one page resume becomes a page and a half with an orphaned final line.
Check: open the file on a device that is not yours. A phone is fine. If the line breaks move, the fonts are not embedded.
4. The portal re-rendered it
Some systems do not store your file. They extract the content and rebuild it in their own layout, or convert it to a different format for the reviewer. You cannot prevent this, and no amount of design survives it.
This is the real argument for keeping the structure simple. A document that carries its meaning in headings, dates, and plain lines survives being rebuilt. A document that carries meaning in columns, colour, and spacing does not.
What this means for how you build the file
- Single column for the main content flow.
- Nothing important in the page header or footer.
- No facts that exist only inside an image, icon, or ratings graphic.
- Standard section headings.
- One consistent date format.
- Fonts embedded, or standard fonts only.
If a portal offers both PDF and DOCX and does not say which it prefers, either is fine when the file is built this way. When they do state a preference, follow it. The preference usually exists because their parser is better at one of them.
How Lynt handles the export
Lynt renders the PDF and then reads it back through a parser, reporting what came out: extraction order, which headings were recognised, whether contact details survived. That is the same copy-and-paste test above, run automatically, on the file you are about to send rather than on the editor's copy of it.
You do not need a product to do this. The paste-into-a-text-editor check catches most of these four failures for free, and takes about thirty seconds.