How an ATS Actually Reads Your PDF (and Why Two Columns Break It)

The thing people find surprising about PDF is that it has no native concept of a paragraph, a column, or even a word. A PDF page is a sequence of drawing instructions: move to this coordinate, set this font, draw these glyphs. The visual layout you see is the result of those instructions being painted onto the page. The order in which the instructions appear in the file (the content stream) is whatever the generating application happened to emit, and it is not required to match the order a human would read.

Most word processors emit text in a sensible order for simple documents: top to bottom, left to right. But once a layout has two columns, a sidebar, a table, or a text box, the emitted order depends on how the application internally represented those objects. A sidebar might be emitted last even though it is at the top left. Two columns might be emitted as alternating lines if the application laid them out row by row. The PDF looks identical either way; only the stream order differs.

An applicant tracking system starts by extracting text from the PDF. The simplest extractors walk the content stream and concatenate the glyphs in stream order. Better ones try to reconstruct reading order from glyph coordinates, grouping characters into lines by their y-position and lines into blocks by proximity. The open-source tool pdftotext (from Poppler) does a version of this and is a reasonable proxy for what a mid-quality commercial parser sees; its -layout flag attempts to preserve columns, and its default mode does not.

Once there is a text string, the parser runs segmentation: find the contact block, find each employment entry (an employer, a title, a date range, and some bullets), find education, find skills. Segmentation relies on patterns (a date range on the same line as, or adjacent to, a title-case line) and on recognisable section headings. If the extraction step has interleaved two columns, those patterns are broken: a date from the sidebar lands next to a bullet from the main column, and the entry boundaries cannot be found.

• Step 1: extract text from the content stream, with or without reading-order reconstruction.
• Step 2: segment into contact, experience entries, education, skills using headings and patterns.
• Step 3: store the fields and index the full text for recruiter search.
• A failure at step 1 corrupts step 2 silently; the application is still 'received'.

Open your resume PDF in any viewer, select all (Ctrl/Cmd-A), copy, and paste into a plain text editor (Notepad, TextEdit in plain mode, or a terminal). What you see is close to what a simple extractor produces. If the result reads as a coherent top-to-bottom document with each job's title, employer, dates, and bullets together, you are in good shape. If lines from different sections are interleaved, if your contact details are missing (they were in a header the viewer skipped), or if your skills are absent (they were an image), that is what the ATS is indexing.

If you have Poppler installed, `pdftotext resume.pdf -` prints the same thing more faithfully. Try it with and without `-layout` to see the difference between a naive and a layout-aware extractor; you cannot know which one a given employer runs.

Two or more columns are the main cause, for the interleaving reason above. Tables used for alignment are second: many extractors emit cell contents in an order that separates a label from its value, and some drop empty-looking cells entirely. Text rendered inside images (skill bars, icon fonts, a name drawn as a logo) has no glyphs to extract and vanishes. Headers and footers are frequently excluded by parsers on the assumption that they contain page numbers, so a contact block placed there is lost. Custom fonts without proper Unicode mappings can extract as garbage characters, which is rare from mainstream tools but common from some design applications.

Every failure above is detectable deterministically: measure whether text blocks share x-ranges (columns), detect table structures, look for text-in-image regions, check the header/footer regions for contact patterns, validate date formats. Ravina's structural check does this without calling a model, which means it is free to run, works offline, and gives the same answer every time. A language model is the wrong tool for the layout question (it never sees the layout) and the right tool for the prose question, which is why Ravina uses your own provider key only for rewriting.