ATS formatting: what parsers actually read

Here is the part of resume writing that punishes you silently. A bullet with a weak verb reads badly and you can see it. A two-column layout that scrambles the parse produces a recruiter staring at an empty candidate profile, and you never find out. The whole discipline on this page is about making sure that a second reader, one made of software, finds the same things a first reader does.

What happens to your file

Every system covered on this site performs the same four steps. The differences between vendors live in steps two and three.

1. Upload. You attach a file to a form. This is the only step the vendor fully controls, and it is the step with the hardest published limits: file type, file size, and whether the file contains text or a picture of text.
2. Text extraction. Something converts your document into characters. A PDF is fundamentally a set of instructions for drawing a page, not a block of text, so a parser either reads the text layer that a word processor embedded or falls back to optical character recognition. This is where image-only resumes die, and it is the one failure every vendor names.
3. Field mapping. The character stream is matched against profile fields: name, email, phone, employer, title, dates. This is where layout matters, because a parser reading two columns has to guess which column a given line belongs to, and a parser reading a table has to decide which cell is a label and which is a value.
4. Human review. Every vendor documents that a person is meant to correct what the parser filled. Greenhouse tells candidates to review the parsed data before submitting all applications. Workday describes resume parsing as populating fields that the recruiter then reviews. Nothing a parser produces is treated as authoritative by the people who built it.

That fourth step is the one worth sitting with. The system is not designed to be the judge of your resume. It is a typing shortcut for the recruiter, and it is allowed to be wrong.

What the vendors document

Five systems are documented in detail on this site, and the table below is the short version. Every claim in it is linked to the vendor's own page, and each vendor has a longer page on this site that separates what is documented from what is inference.

Documented resume parsing behaviour, by vendor

Vendor	Documented limit	Publishes failure modes
Greenhouse	Will not parse a file larger than 2.5 MB	Yes, a named list of the formatting that breaks a parse, including columns, tables, headers, footers, text boxes, graphics and letter-spaced words
Workday	DOCX and PDF, where the PDF "must contain text that's not image-based"	Yes, in full. Its developer documentation publishes parsing guidelines for people writing resumes, not just for integrators
Oracle Taleo	Set by the employer's own configuration	Indirectly. Oracle documents parsing as a third-party service delivered as is
Lever	.doc, .docx, .pdf, .txt up to 10 MB	Partly. It documents which fields parsing populates and that a hosted-site setting can disable email parsing
iCIMS	Word or PDF, per customer configuration	Only at the level of a product explainer. Behaviour is per customer and not published

Read that table as a floor rather than a ceiling. A single company can change parser settings, turn parsing off entirely, or run a different system behind the careers page than the one named in the footer. You cannot tell from outside which situation you are in, which is precisely why the safe move is the layout every vendor's documentation points at.

Six layout habits that break a parse

These are the six that appear in the vendors' own failure lists, with the fix beside each one. Nothing on this list is a style opinion.

Formatting habits documented as causing a failed resume parse

The habit	What the vendor says	Do this instead
Two or more columns	Greenhouse lists "resumes that have a columned layout" as a parse failure. Workday says to "avoid tabular and column formats."	One column. If a sidebar is genuinely the point of the design, read the two-column guide before you decide
Tables used for layout	Greenhouse names "complex resumes with tables, headers, and footers." A table makes the parser choose between reading across and reading down.	Use a real list, or space the fields with tabs and rules in a way that keeps one fact per line
Name and contact in a header, footer or text box	Greenhouse names it. Workday says to "avoid personal information in the header and footer sections, such as name, phone and address."	Put them in the body, in the first four lines, in initial capitals
Graphics, photos, logos, skill bars	Greenhouse lists "graphics, photos, or word art" and uploads that are "an image, rather than a document." Workday says to avoid "visual objects such as images, text boxes, clip arts, logos, and annotations."	Nothing. A five-point proficiency bar communicates nothing a word does not, and it is a second file-size problem
Letter-spaced words	Greenhouse is unusually specific: a word with spaces between the letters "won't be recognized as a single word and can't make sense of the data."	Letter spacing for a design effect. It is the most counter-intuitive entry on the list, because to a reader it is a strong visual choice
One heading covering two sections	Workday is explicit: provide proper headings such as EDUCATION and EXPERIENCE, and "don't combine multiple sections under a single heading such as EDUCATION and EXPERIENCE."	One heading, one section. Its parser returns a fixed set of named sections and a combined heading lands in none of them

Notice that four of those six are invisible to the person who designed the page. The letter spacing looks deliberate. The logo looks professional. The text box is how the tool placed the name neatly. The failure only exists in the gap between what a person sees and what a line of extracted text says, which is why this is the one area of resume writing where you cannot check your own work by looking at it.

Dates, and why they break first

Dates matter more than they look like they matter, because a date is not a fact on your resume. It is the fact the parser uses to attach everything else to. If the date for a job ends up on the wrong entry, or inside the previous entry's bullet, the employment history the recruiter sees is quietly wrong. Nothing marks it as wrong, and nobody notices for a week.

Three things cause this. The first is a mix of formats, which no reader minds and every parser does. The second is a date set in a text box or a right-aligned tab stop far from the role it belongs to. The third is a date format the parser cannot resolve, and the resolution depends on the region the tool is configured for rather than the region you are in.

Workday publishes the label it looks for, which is unusually helpful. Its documentation gives the literal form Date: Jan 2015 – Present. Unambiguous month name, four-digit year, explicit present. Greenhouse separately flags abbreviated job titles as hard to resolve, and the same ambiguity applies to abbreviated and ambiguous dates.

Three changes, all mechanical. Every date is spelled the same way, with the month named rather than numbered, which removes the March-versus-May problem entirely. The overlapping roles are declared in plain text instead of left to look like a mistake. And the employer names carry their suffix, which is a documented Greenhouse rule rather than a style choice.

Names, employers and job titles

Three fields cause disproportionate damage for a specific reason: they are the fields a parser matches against a database to decide whether this is a new person or an existing one. Get them subtly wrong and you do not get a worse score, you get a duplicate profile or a person who cannot be found later.

Workday is the most prescriptive vendor here, and its published rules are worth following literally rather than approximately. It asks that you start the name with the hint Name: Xxxx Yyyy, that names appear on separate lines, that the candidate's name sits at the top of the document, that multi-word names start with initial capitals or full capitals, and that you avoid writing names in all lower case. It gives literal examples for the other fields too, including Email:, Mobile Phone: and Date:. Labelled hints are not a hack. They are the documented input format.

Greenhouse adds two rules from the other direction. It documents that company names lacking identifying words such as Inc., Co., Ltd or LLC cause problems, and that incomplete job titles such as "Sr. Account Exec" are hard to resolve against the full form. The reason is the same in both cases: matching is done against stored strings, and an abbreviation is a lookup that can miss.

The right-hand version is not badly made. It is somebody's best work with a word processor. It fails on four counts at once: the letter-spaced name, an icon instead of the word before the email address, the abbreviation of the job title, and a location that a recruiter in another country cannot place. None of it is visible as a mistake. That is the point.

The file itself

Two properties matter and both are documented: whether the file contains text, and how large it is.

Text. Workday's condition on a PDF is that it "must contain text that's not image-based." Greenhouse lists uploads that are "an image, rather than a document (such as a .docx or a .pdf)" as a failure. These sound like different rules and they are the same rule seen from two directions. A PDF saved from a word processor contains text. A PDF produced by scanning a page, or by printing to PDF from a document that embeds your resume as a picture, does not.

Size. Greenhouse stops at 2.5 MB. Lever accepts up to 10 MB. Use the tighter number. An ordinary one-page resume exported without images is tens of kilobytes, so crossing 2.5 MB requires a deliberate act, and that act is nearly always an embedded photo or a full-bleed background. Greenhouse names high-quality images as the reason people hit the ceiling. If your export is suddenly enormous, that is what happened, and the fix is to delete the image rather than compress the file.

Test your own file in five minutes

This is the part that converts the whole page from advice into a check. It takes less time than the last email you sent, and it is definitive rather than hopeful.

1. Open the exported file, not the document you edited. The file you are about to upload, from disk, in a fresh window. The version in your editor is not the version under test.
2. Select everything and copy it. Ctrl and A, then Ctrl and C, on a Mac Command and A and C.
3. Paste it into a plain text editor. Not a word processor, which will re-apply formatting and hide the problem. Notepad, TextEdit in plain text mode, or any editor that shows you nothing but characters.
4. Read it in order. Is your name the first thing? Is each date next to the job it belongs to? Did anything merge, or move a line, or come out twice? Two-column layouts fail here. Tables fail here. Text boxes fail here.
5. Check the file size. If it is over 2.5 MB, find the image and remove it, then export again.

If the text comes out in the order you meant, the file is sound for a text-based parser. That is as close to a guarantee as this problem allows, and it costs one coffee's worth of attention per application, or a single check per version if you reuse one export.

The compliant checklist

Every line below is a restatement of a rule one of the vendors published, with nothing added for style.

• Text-based file. DOCX, or a PDF with a text layer. Never a scan, never a flattened image.
• Under 2.5 MB. The Greenhouse ceiling, and the tighter of the two published limits.
• No graphics, photos, logos, icons, or skill bars. Named independently by Greenhouse and Workday.
• No letter spacing on words. Greenhouse states it stops the parser recognising a word.
• One column. No sidebar, no parallel skills column, no newsletter-style rail.
• No tables used for layout. A table makes the parser choose a reading direction it cannot verify.
• Name and contact in the body of the first page, in initial capitals, in the first four lines. Not in a header, footer or text box.
• Standard section headings, one per section. EXPERIENCE, EDUCATION, SKILLS. Do not merge two under one heading.
• One date format everywhere. Month name plus four-digit year, with an explicit present or end date.
• Employers written out with their suffix where they have one, and job titles spelled out in full rather than abbreviated.
• Bullets at the start of every line inside an entry, so one entry cannot bleed into the next.

For the long form of each of these, with the vendor's own wording and a link to the source, see the vendor reference, and then the page for the system you are actually applying through: Greenhouse, Workday, Oracle Taleo, Lever, iCIMS.

Where the rules above come from

Every claim on this page is drawn from the vendor's own published documentation. None of them is a statistic, and none of them is us describing how a parser behaves on average. These are the documents, so you can check any line of the checklist against the source and see whether it still says what it said when this page was written.

• Greenhouse Support — Unsuccessful resume parse: the 2.5 MB limit, the named list of formatting that breaks a parse, and the placeholder-data rule.
• Workday Developers — Resume REST API: the "Resume Guidelines for Improved Parsing Results" section, including the layout, structure, name and labelled-hint rules, and the accepted file types.
• Workday Documentation — Concept: Resume Parsing: the fields Workday will not auto-fill.
• Lever Support — Understanding Resume Parsing: accepted file types and the 10 MB limit.
• Oracle — Profile Import Options for Candidates: how Taleo treats parsing as a configured, third-party service.
• iCIMS — What is CV/Resume parsing?: the product explainer, and the limit of what it documents.

Vendors change their documentation, and a parsing rule that was accurate when this page was written may have moved. That is the one caveat worth carrying: the rules are quoted, not inferred, so you can re-check them, and you should.

Questions about parsing