ATS resume format: layout rules that survive every parser

Advice about ATS resume format tends to arrive as a list of superstitions: never use two pages, never use color, never use PDF, always repeat keywords three times. Most of it is folklore that has never been near an actual parser. We test formatting against parsing tools as part of building Workplacea's templates, so this guide takes a different approach — for each layout decision, we tell you what extraction actually does with it, what fails, what is harmless, and what is merely someone's decade-old guess repeated until it hardened into a rule.

One framing note before the rules: no mainstream applicant tracking system rejects a resume because of its format. The stakes of formatting are accuracy — whether the parsed version of you that recruiters read and search matches the resume you wrote. That is worth getting right, and it requires none of the paranoia. The broader context is in our ATS resume guide.

Section headings parsers recognize (and creative ones they don't)

Parsers segment your resume before they extract details: this block is experience, that block is education. Segmentation keys heavily on headings, and it is trained on the conventional ones.

Reliably recognized: Work experience, Professional experience, Experience, Education, Skills, Certifications, Licenses, Summary, Projects, Publications, Volunteer experience.

Risky: "My journey," "Where I've been," "What I bring," "Toolbox," "Superpowers." A parser that cannot classify a heading may misfile everything beneath it — we have watched an entire work history land in a generic notes field because it lived under a clever label. The recruiter's summary view then shows a candidate with no experience.

Two supporting rules. Make headings visually distinct — their own line, bolded or sized up — because some parsers use styling as a segmentation cue. And keep sections conventional in order and count: contact information, summary, experience, education, skills, plus extras as needed. Guidance on choosing among chronological, functional, and hybrid structures lives in the resume format guide; all three can parse cleanly, though the reverse-chronological structure matches parser expectations best.

Date formats that parse correctly every time

Dates are the highest-stakes field in parsing, because systems compute tenure from them and recruiters filter by them. They are also where we see the most avoidable errors.

Safe formats, tested:

• Jan 2022 – Present
• January 2022 – March 2024
• 01/2022 – 03/2024
• 2019 – 2023 (parses fine, but month-level dates read as more transparent to humans)

Formats that cause trouble:

• Seasons: Spring 2023 has no standard month mapping; some parsers drop it entirely.
• Duration-only: 2 years gives the parser nothing to anchor.
• Stacked or offset dates in a separate column — the date can attach to the wrong job when reading order breaks (more on columns below).
• Ambiguous numerics like 03/04 — month and year, or day and month?

Pick one format and use it for every entry. Consistency is not just aesthetics; parsers infer your entry structure from repetition, and one inconsistent line — dates before the title in a single role, say — can break field mapping for that entry. Here is a real example from our testing: the line Operations Lead 2019 Chicago — Meridian Foods parsed with "2019 Chicago" absorbed into the job title. Restructured as Operations Lead — Meridian Foods, Chicago | 2019 – 2022, every field mapped correctly.

Bullets, symbols, and special characters: safe vs risky

Safe: standard round bullets, hyphens, en and em dashes, ampersands, plus signs, slashes, percent signs, accented characters, and the punctuation of ordinary prose. All extract cleanly from any competently generated file.

Risky:

• Decorative bullet glyphs — arrows, stars, chevrons, checkmarks — usually extract as junk characters or drop out. Harmless to meaning, ugly in the parsed view. Round bullets read identically and cost nothing.
• Icon-font symbols for phone, email, and location. These are letters remapped by a display font; extracted without the font, they can turn into stray characters beside your contact details. Use words or nothing.
• Emoji. Extraction is unpredictable, and they do not belong on a resume anyway.
• Ligatures and smart substitutions from design tools can occasionally garble letter pairs ("fi" for "fi") in poorly generated PDFs — a file-generation issue you will catch with the paste test described below.

The test that settles any symbol question in ten seconds: export, select all, paste into a plain-text editor. Whatever survives is what a parser gets.

Columns, tables, and graphics: parser test results

The big three layout risks, with what our testing consistently shows:

Tables. Text placed in table cells can be extracted row-by-row or column-by-column depending on the engine. A layout table with dates left and duties right sometimes parses perfectly and sometimes welds every date into one block. Because you cannot know the employer's parser, tables are an uncontrolled risk with zero content payoff — everything a table does visually, tab stops and spacing can do safely.

Two-column layouts. Same ambiguity at page scale. Results in our testing ranged from flawless to sidebar text interleaved mid-sentence into the main column. The full experiment, with per-parser results, is written up in two column resume and ATS. Single column is the only layout that parses correctly everywhere.

Graphics. Parsers extract text, not images. Skill bars, rating dots, charts, and logos vanish silently — and anything they alone communicated vanishes with them. Decorative graphics are harmless; informational graphics are self-deleting. Headshots also vanish, which in most markets is fine because they should not be there anyway.

Headers and footers. Some extraction engines skip these page regions. Contact details in the document header — a common template design — can disappear entirely, producing the worst possible failure: an unreachable candidate. Keep contact information in the document body. More template-level failure patterns are cataloged in our ATS friendly template guide.

File format for ATS: PDF vs DOCX, tested per system

The short version: a text-based PDF and a clean DOCX both parse well in every major modern system — Workday, Greenhouse, Lever, iCIMS, Taleo included. The "never send PDF" rule dates from an era of weaker PDF extraction and deserves retirement.

The decision rules that still matter:

1. The posting wins. If it requests a specific format, comply. This is also a reading-comprehension test.
2. Default to PDF when no preference is stated. It locks your layout so the human view is exactly what you designed.
3. Confirm your PDF is text-based. Select-all-copy-paste: if you get your resume's text, you are fine. If you get nothing, your PDF is an image — the one file type that reliably parses as a blank candidate. This happens with scans and with some design-tool exports.

The full comparison, including edge cases like older systems and DOCX quirks, is in PDF or Word resume.

The clean-format template, explained element by element

Here is the skeleton we use for Workplacea's most conservative template, with the reason each element earns its place:

• Name on the first line of the body, largest text on the page. First-line text is where parsers expect a name; size confirms it.
• Contact line directly beneath: phone, email, city and state, LinkedIn URL — plain text, one line, in the body.
• Summary (optional), three lines maximum, under a "Summary" heading.
• "Work experience" heading, then entries in reverse-chronological order, each formatted identically: Job title — Employer, City, ST on one line, Mon YYYY – Mon YYYY with it or on the next, then three to six round-bullet achievements.
• "Education": degree, institution, year. Same pattern every entry.
• "Skills": a plain list or short categorized lines. No graphics, no proficiency dots.
• Layout: one column, 0.5–1 inch margins, a standard font at 10–12pt, section headings bolded. No tables, no text boxes, nothing in the page header or footer.

Nothing about this skeleton is visually exciting, and nothing about it prevents good typography, judicious color, or clear hierarchy. It is simply a structure whose parsed output we have verified matches its content — every field, every time.

Frequently asked questions

Does an ATS reject resumes with the wrong format?

No. Formatting failures corrupt the parsed data recruiters see and search; they do not trigger rejection. The one true formatting catastrophe is an image-only PDF, which parses as empty — and even that results in a blank-looking candidate record, not an automated rejection letter.

Is a two-page resume a problem for parsing?

Not at all. Parsers process multi-page documents without difficulty. Length is a human-attention question, not a parsing one.

Are color and shading safe?

Yes. Parsers read text irrespective of color. Two cautions: keep contrast readable for humans, and never use white-on-white text for keyword tricks — it extracts fine and appears verbatim in the recruiter's parsed view, which is exactly where you do not want it discovered.

Do I need different formatting for Workday versus Greenhouse?

No. Parser quality varies across systems, but the conservative choices above parse correctly in all of them. One resume, formatted cleanly, serves every system — spend your per-application effort on content instead.

Verify the format, then forget about it

Formatting is the rare resume problem you can fully solve once. Run your file through Workplacea's free resume checker and read the parsed output field by field — if your titles, dates, and contact details come through intact, your format is done, and every future hour belongs to the bullets. Prefer to start from a layout that is already verified? Every template in the editor ships with its parsing results published.