What format do ATS systems actually read?

Almost every job application you send goes through a piece of software before it reaches a person. That software has to turn your PDF back into structured data — name here, employer there, dates in this field — and it is much worse at it than people assume. Most advice about "beating the ATS" is folklore. This is what actually happens, and what actually breaks.

What an applicant tracking system actually is

An ATS is a database with a hiring workflow attached: Workday, Greenhouse, Lever, Taleo, iCIMS, SuccessFactors. Its job is to store applications, move them through stages, and let a recruiter search them. Parsing your resume is a small feature of a large product, and it is usually handled by a third-party library nobody at the company chose deliberately.

Two myths worth killing first.

It does not score you out of ten and bin you. Some enterprise systems can rank candidates against a requisition, and most recruiters do not use that feature. What almost always happens is simpler: a recruiter types "Kubernetes" or "staff engineer" into a search box, and either you appear or you do not.

It does not read your PDF the way you see it. A PDF does not contain paragraphs, columns or sections. It contains instructions to place glyphs at coordinates. Every piece of structure a parser gives you — this is a heading, this line belongs to that job — is inferred from position, size and weight. Everything below follows from that one fact.

The things that genuinely break parsing

Multiple columns

This is the big one. If your resume has a narrow left sidebar for skills and a wide right column for experience, the text is laid out in two independent streams. A parser walking glyphs by vertical position reads across both at once, and you get output like "Skills Senior Engineer Python Acme Corp Docker 2021–2024". Not ruined exactly, but every field is now polluted with fragments from the other column.

Single column, full width, top to bottom. A two-column skills list is usually fine, because the two halves are short and self-contained — but the main body of the document should never be two columns.

Tables

Tables are the second most common cause of scrambled output. A table cell has no reliable reading order, and different libraries traverse them differently — some by row, some by column, some by position on the page. If your employment history is a table, two parsers can produce two different careers for you.

Lay out rows with tab stops or right-alignment rather than a table grid. It looks identical and extracts in reading order. Every template here does it that way.

Headers, footers and page numbers

A PDF header is not semantically a header; it is text near the top of the page. Put your name and phone number in a header and a fair number of parsers will either drop it — because they trim repeated page furniture — or file your phone number as part of your first job. Put your contact details in the body of the document, at the top, as ordinary text.

Images of text

Obvious when stated, easy to do by accident: a logo containing your name, a skills section drawn as a chart, a signature image, or a resume exported as a flattened image. A parser extracting text finds nothing there. Rating your own Python ability as four filled circles out of five conveys precisely zero characters to the system, and arguably zero information to the human too.

Non-standard section names

Parsers find section boundaries by matching your headings against a known list. "Experience", "Work Experience", "Professional Experience", "Employment", "Education", "Skills" and "Projects" are recognised everywhere. "Where I've Made An Impact" and "My Toolkit" are recognised nowhere, and the content under them gets attached to whatever section was last identified.

Be boring in your headings. Spend the creativity on your bullets.

Glyph encoding problems

This one is invisible until you test for it. Some fonts, and some PDF generators, emit text whose characters do not map back to readable Unicode — you select it, copy it, and get gibberish or nothing at all. Ligatures are a common culprit: "fi" set as a single ligature glyph can extract as a character no search will match, quietly breaking the word "profile" in a keyword search.

What matters much less than people claim

• File format. PDF is fine, and has been for years. Some portals still ask for .docx; if a form asks, give it what it asks for. Nobody is filtering you out for sending a PDF.
• Keyword density. There is no threshold to hit. A recruiter searches for a term and you either have it or you do not; the fifth mention buys nothing. White text stuffed with keywords is an integrity problem at some companies, and modern parsers extract it anyway, so it is visible.
• Fancy fonts. A parser does not care whether you used Helvetica or Palatino. It cares whether the glyphs map back to text.
• Exact page dimensions. A4 versus US Letter changes nothing about parsing.

How to test your own resume in two minutes

This is the only test that matters, and it costs nothing:

1. Open your PDF in any reader.
2. Select all the text, and copy it.
3. Paste it into a plain text editor.

What you see is approximately what the parser sees. Read it. Is your name first? Are your job titles attached to the right employers? Are the dates intact? Did your skills section land in the middle of a job description? Is anything missing entirely?

If the plain text reads like a sensible document, you are fine. If it reads like two documents shuffled together, you have a column problem. If parts are missing, they were probably images. This single check catches nearly every real parsing failure, and almost nobody does it.

Where this leaves the actual design

The constraints are narrower than they sound, and they are all satisfied by conventional typography: one column, real text, standard headings, no tables, nothing in the margins. That is not a compromise — it describes most good resumes of the last forty years.

It is also exactly what LaTeX is good at, which is why everything ResumeX compiles is built this way. Each template sets real selectable text in a single column with conventional section names and nothing in the headers or footers. If you want the plainest possible version of that, Onsite sans was drawn to be unremarkable on purpose. If you need to fit a long career into the space, Signal and Compact sans tighten the typography rather than the structure. If your evidence is mostly academic, Dense academic puts education first.

And whatever you use, run the copy-paste test before you send it. Then fill in the sheet and read the page that comes out.

The short checklist

• One column for the main body
• No tables for anything a parser needs to read
• Contact details in the body, not in a page header
• Standard section names
• Real text, not images — verify by copy-pasting
• PDF unless the form specifically asks otherwise
• No keyword stuffing, visible or hidden