ATS

The best resume format for AI screening, once you know what the machine is

Search for resume advice about AI screening and you get confident formatting rules with nothing underneath them. The reason it all sounds the same is that it treats two different systems as one. There is a parser that turns your file into data, and vendors do document what breaks it. Then there is a ranking layer that scores the result, about which almost nothing is published. Format for the first, write for the second, and ignore anyone who claims format tricks sway a model nobody outside the vendor has seen.

Two stacked panels. The parsing layer lists four documented format rules with ticks. The ranking layer below it is an empty dashed box reading not published.

The short answer

Use one column, standard section headings, and real text for anything you need a machine to read. Keep your name and contact details in the body of the document, not the header. Skip graphics, icons, and skill charts. Export a text-based file, not a scan.

That is the whole documented format story. Everything beyond it, every claim that a particular template or font or layout scores better with the AI, is a claim about a system its author has not seen inside. The useful work beyond formatting is in the words: covering the job description's actual requirements, in its actual phrasing, honestly.

  • Documented: parsing failure modes, which are format problems.
  • Not documented: how any ranking model weighs anything about format.
  • Always yours to control: whether the requirements the posting names appear truthfully in your resume.

AI screening is two machines wearing one name

When people say AI resume screening they are pointing at a pipeline with two very different layers in it.

The first is parsing. Your file arrives and software extracts names, dates, employers, titles, and skills into database fields. This layer is old, boring, and it matters: if extraction goes wrong, every later step works from wrong data. It is also the one layer whose behaviour is documented, because parsing vendors publish what their systems can and cannot read.

The second is evaluation: whatever ranks, scores, or filters the parsed candidates. This is where the actual artificial intelligence lives when it lives anywhere, and it is where documentation stops. Which model, trained on what, weighing what features: not published.

The two get merged even by careful writers. ORISE, a US Department of Energy institute, opens its formatting advice by describing AI systems that screen resumes as commonly known as applicant tracking systems. The University of Pennsylvania's career services page treats applicant tracking systems and AI scanners as one category with one set of rules. Neither is being careless by the standards of this genre. The words themselves are blurred, and once you see that you can read every AI-format article correctly: the checkable rules are parser rules.

The rules that are actually documented

Strip away the AI framing and the reliable format guidance is a short list, and it is the same list the parsing documentation supports.

Single column, top to bottom. Multi-column layouts force the extractor to guess reading order, and a wrong guess scrambles which dates belong to which job.

Standard headings. Experience, Education, Skills. The extractor is looking for sections it recognises, and a heading like Where I Have Made Impact defeats pattern-matching that Work Experience would have passed.

Nothing important in the page header or footer. Penn's career services guidance is blunt here: do not use headers and footers, because they can prevent the system parsing your information correctly. Contact details are the classic casualty.

Real text only. Skill charts, icons, and text baked into images extract as nothing at all. Penn's list flags graphics and symbols for the same reason.

We keep a running page of what six major systems' own documentation says about parsing, and the pattern across all of it matches this list: the documented risks are about structure, not about how the page looks. Fonts, colours, and visual polish are for the human who reads you after the machine does.

The layer nobody outside can see

Now the honest part. Once your resume is parsed into clean data, how the evaluating layer scores it is not published by any major vendor. Anyone who tells you the AI prefers this template, rewards that font, or scores two-page resumes lower is describing a system they have not seen. Some of these claims may even be true. The point is that nobody selling you a format can know that.

What you can reason about is the input. Every description of these systems, including ORISE's, agrees on the basic mechanism: the screening compares your resume against the job posting. So the lever you actually hold is coverage, in plain sight: the requirements the posting names, appearing in your resume, in wording a literal matcher can connect.

Penn's guidance makes this concrete with an example worth keeping: if the description asks for leadership experience, include the exact phrase leadership experience rather than only listing leadership roles. Wording a human would treat as equivalent may not be credited by a system matching text.

The boundary on this is the same as ever: the phrase has to be true. Matching the posting's language for experience you have is tailoring. Adding requirements you do not meet is fabrication, and it is the human reader, who arrives eventually, that it fails in front of.

Sometimes you are told the AI is there. Read the notice.

One genuinely new fact separates 2026 from the older ATS era: in some places, AI screening is regulated, which means it is disclosed.

New York City's Local Law 144 sets three conditions before an employer may use an automated employment decision tool. The tool must have had a bias audit within the past year. Information about that audit must be publicly available. And candidates must be given notice, ten business days before the tool is used.

For a job seeker this matters in a way that has nothing to do with formatting. When you apply to a covered NYC role, the notice and the published audit summary are the only first-party record of the screening you will ever see. They tell you a tool is in use, and sometimes which one. That is more than any formatting article can tell you.

Similar rules exist or are arriving in other jurisdictions, and some employers disclose voluntarily. It costs one minute to search a careers page for an AI or automated-tool notice before applying, and what you learn is real in a topic full of guesses.

The hacks are format advice's evil twin

Every few months the same tricks recirculate: white text stuffed with keywords, font-size-zero paragraphs, and lately, instructions addressed to the language model hidden in the file.

Notice what these have in common with the confident template claims: both are bets on the layer nobody has documented. The hack assumes hidden text reaches the model and sways it, and that no later stage notices. Neither assumption is checkable from outside, and the downside is one-sided. Hidden text is still text. It sits in your file, the parser pulls it out, and anyone reading the parsed record can see it. A resume that says one thing to machines and another to people has a trust problem no formatting can fix.

If the screening layer bothers you on principle, that is a fair position with a real decision attached, and we have written separately about when opting out of AI screening makes sense. Gaming the layer is the worst of both: you accept the machine and lie to it.

The format checklist, and what to ignore

Here is the whole checklist we can stand behind. It is short because so little is documented.

Everything else you have read, template rankings for AI, font recommendations for AI, one-page rules for AI, is either human-reader advice wearing a machine costume or a guess about a hidden system. Some of it is fine advice for the human. None of it is documented machine behaviour.

To see your own resume the way a parser sees it, use a checker that shows its reasoning rule by rule, like ours. It tells you which of these structural rules your file passes, rather than handing you a number to worry about.

  • One column, reading top to bottom.
  • Standard headings: Experience, Education, Skills.
  • Name and contact details in the body, never the header or footer.
  • No graphics, icons, charts, or text inside images.
  • A text-based export, not a scanned or photographed page.
  • The posting's own phrasing for requirements you truthfully meet.
The two-column template
Before

A sidebar holds skills and contact details beside the work history.

After

One column, with skills as a labelled section under the work history.

Why it works

Reading order across columns is a guess the extractor has to make, and it is one of the failure modes vendor documentation actually names. The single column removes the guess.

Contact details in the header band
Before

Name, email, and phone sit in the document's page header.

After

The same details as the first lines of the document body.

Why it works

Do not use headers and footers is one of the few flat rules in Penn's guidance, because header content can be skipped at parse time. Losing contact details is the most expensive version of that failure.

The skills chart
Before

Proficiency bars rate Python at four dots out of five.

After

A plain list: Python, SQL, dbt, matched to the posting's own terms.

Why it works

Graphics extract as nothing, so the machine reads a blank where your skills were. Four dots is also a rating no reader can interpret, so the chart was serving neither audience.

The equivalent phrasing
Before

Ran a team of six across two functions.

After

Leadership experience: led a team of six across two functions.

Why it works

Penn's example is exactly this case: a description asking for leadership experience is best answered with that phrase, because a system matching text may not credit the reworded version. The claim underneath must stay true. Only the wording moves toward the posting.

What we read, and the limits of it

This article draws on four sources: the University of Pennsylvania's career services guidance on AI scanners, ORISE's formatting advice for AI screening, New York City's published material on Local Law 144, and the vendor parsing documentation we keep a sourced page of. Each was read on 30 August 2026.

The limit to be honest about: no source here, and none we could find anywhere, documents how any production ranking model treats resume format. Our claim is not that format cannot matter to that layer. It is that nobody selling format advice can know, and the rules that are knowable all live at the parsing layer.

One habit worth flagging, because it shapes this whole genre. Career-office pages often relay adoption statistics that originate with companies selling resume tools, measuring their own detection and publishing the result as marketing. We have left those numbers out. Nothing in this article depends on how many employers use these systems, only on what the systems themselves document.

Common questions about resumes and AI screening

Is there a resume template that beats AI screening?

No template can be shown to beat the ranking layer, because no vendor publishes how that layer treats format. What a template can do is pass the parsing layer, and the requirements for that are documented and simple: one column, standard headings, real text, nothing important in headers or footers. Any plain template meets them.

Do fonts or colours affect AI screening?

There is no documented evidence that fonts or colours change any screening outcome, provided the text remains real, selectable text. Choose them for the human reader: legible at a glance, printable, nothing that costs contrast.

Should I use PDF or Word for AI screening?

Either works when exported as real text from a word processor or builder. The failure case is the scanned or photographed page, where there is no text layer to parse at all. If a posting specifies a format, that instruction beats any general rule.

Does hidden white text help get past AI screening?

It is a bet on a system nobody outside the vendor has documented. The hidden text is still text: the parser extracts it, and anyone reviewing the parsed record or the file can see it. A resume that reads differently to machines and people creates exactly the trust problem a screening process exists to catch, and no published evidence shows the trick improving outcomes.

How do I know if AI screened my application?

Usually you do not, and honest advice says so. The exception is where disclosure is required: under New York City's Local Law 144, employers using an automated employment decision tool must notify candidates in advance and publish bias-audit information. When you see such a notice, it is the only first-party documentation of the screening you are likely to get.

What this article relies on

Check the documented layer

The parsing rules are the part of AI screening you can actually verify. Run your resume through a checker that shows which structural rule passed or failed and why, then spend the saved worry on the words.