How to Format an ATS-Friendly CV Parsers Can Read

In brief. Use a single-column body, standard headings, plain paragraphs and bullets, contact details in the body of page one, one consistent date style, and a text-based file the posting accepts, then confirm you can select and copy the text. A parser stores a sequence, not the page you designed. Wrong order, and the right words can miss the right section.

Three things to remember

1. A parser gets a stored text sequence, not the visual page.
2. Columns, tables, headers and footers, text boxes, and icons can drop or scramble content that is still in the file.
3. File type follows the posting when it names one, and no layout guarantees a parse, an interview, or a job.

What "ATS-friendly" means on the page

You read a resume as a page with a top, a bottom, and rails along the side. A typical parser does not.

Call the file a CV or a resume. The reading problem doesn't change.

It gets a flat text sequence. Section assignment depends on that stored order being right. Mix the order and a job can land under Skills. A phone number can drop out of the contact block while it still sits in the file, visible to you and invisible to the step that files the application.

Thing is, stored order often differs from visual order. You built a left rail and a right rail, and the file may have saved one rail, then the other, or interleaved the lines, which is the quiet mix-up that leaves a whole job in the wrong bucket while the page on your screen still looks fine. Content can exist in the file and still sit where automated systems skip it. ATS Preview lays out that gap between the page you see and the sequence a parser stores.

A typical PDF makes the trap easier to miss. It has no native column. It stores draw instructions for glyphs at coordinates. That's a map of where ink sits. It's not a promise of reading order.

A parse is not a job offer. A readable file is still worth sending when you apply to large employers. Jobscan reports a detectable ATS on 487 of 500 Fortune 500 career sites, 97.4%, in its 2026 report.

Earlier cited years in that same audit series stay in a high-97% to 98% band. Treat the 97.4% figure as Jobscan's reported count, not an independent census, and not proof that software auto-rejects applicants. Detectable tracking software is a reason to make the file parseable. It isn't a hiring outcome.

Don't merge that audit with a different 2026 method. Nanoscrape's signature scan found 103 of 500 Fortune 500 careers pages (20.6%) unmatched to a commercial ATS signature, and 50 (10.0%) pending a browser check. Don't treat them as one count.

Custom microsites and hand-built portals can miss a commercial signature. The scan doesn't say those employers skip human review. It also doesn't make formatting irrelevant.

Layouts that keep reading order intact

Pick each element by what usually preserves reading order, not by how sharp the page looks when you preview it on screen. Looks are not the real test.

The comparison below is repeated practitioner guidance. It's not a test of every vendor product, and these elements don't fail on every system. Write-ups such as Resume Atlas keep flagging the same traps. One checklist allows a "simple two-column," which is looser than the repeated guidance. Single-column is still the safer default. Use that default when the posting doesn't specify a template.

Choice	Usually keeps reading order	Often scrambles or drops text
Columns	Single-column body	Two-column layouts
Tables	Experience, skills, and education as paragraphs and bullets	Content placed in table cells
Text boxes and floating shapes	Text in the normal flow of the page	Text boxes and floating shapes, which can omit what sits inside
Headers and footers	Contact lines and bullets in the main body	Contact lines or bullets that live only in a header or footer
Icons, bars, ratings, dots	Skill names written as plain text	Icons, skill bars, star ratings, and colored dots, which can be read as garbage or ignored
Section titles	Standard headings such as Work Experience, Education, and Skills	Creative or non-standard titles that can cause a parser to skip the block
Contact placement	Name, email, and phone in the main body, top of page one, above the summary	Contact details only in a header or footer

Don't park the phone in the header. That version looks tidy on screen and can vanish from the text a parser stores. Put the name, email, and phone in the body, above the summary, on page one. Same facts. Different compartment.

Write skills as words, since a bar, a star, or a colored dot is not a skill name. Guides describe a plain single-column file as clean and professional, not inherently dull, and a sharper two-rail template can still swap a job with the skills rail. Keep the single-column file as the default.

One guide advises against colored text. Treat that as a single-source caution, not a ban every portal enforces.

Headings, dates, and type that stay plain

Tenure math needs dates a system can compare.

Turns out one style has to show up on every role, and you should spell the month when you can. Guides show lines such as May 2023 to present, Mar 2023 - Present, and Jan 2026 - Dec 2026. An explicit month plus a four-digit year, such as 03/2023 - Present, appears too. Don't mix 05/2023, '23, and now. The problem is the mix, not one fragment used alone and used everywhere.

Work Experience, Education, and Skills are standard labels to keep, and a witty stand-in can cause the block under it to be skipped. You don't need a private vocabulary for sections. You need headings the software is likely to recognize.

Common tips name Arial or Calibri, with body text about 10-12 pt and not below 10 pt, section headings about 12-14 pt bold, and contact text about 10-11 pt. Margins are often given as about 0.5-1 inch on all sides.

A gap of about 6-12 pt after sections or paragraphs shows up often, with line spacing about 1.0 or 1.15 rather than 1.5 or double, unless the file is very short. These are commonly repeated practitioner ranges. They are not measured ATS tolerances.

Formatting notes for international applicants to U.S. jobs

CV Owl writes for international professionals applying to U.S. jobs, and it calls non-standard formatting a common parsing problem. Columns, images, and lines can stop software from reading the information correctly. Mismatched date styles can confuse a parser.

Repeating a buzzword many times is not enough. Use the plain layout above: one column, standard headings, one consistent date style with the month spelled when you can, no graphic bars. Call that a formatting note only. It's not guidance on visas, credential evaluations, pay, or contracts.

PDF or Word: match the posting, then check the text

PDF and Word are the choice people want settled. Sources still disagree.

Some guides say submit DOCX unless the posting asks for PDF, and they describe DOCX XML as parsing reliably. ATS Grader treats a clean single-column text-based PDF as fine on many modern systems, and as a file many recruiters prefer to open. It treats DOCX as the safer default for older portals, government or defense boards, or postings that request Word. The government-or-defense line is one guide's advice, not an agency rule.

To be honest, a line that tells you to prefer PDF most of the time has no measured basis. Ignore it.

Follow the posting. The file has to be text-based. You must be able to select and copy the words. If you can't highlight them, a parser is likely to see little or nothing.

Avoid Print to PDF. Print to PDF can create an image-based PDF. Native Google Docs files are often not accepted, so export before you upload. A complex multi-column PDF is described as parsing worse than a simple single-column DOCX. Converting the extension doesn't fix the layout.

If the posting is silent, pick one text-based format and export a simple file. Do not rescue a two-column design by renaming it.

Layout still dominates the extension. Prefer the safer side of the table. When the posting names Word or PDF, send that. When it doesn't, don't declare a universal winner.

Check the exported file before you upload

Export first, in the text-based format you will upload, and only then test what the file stored. Your editor preview is not that file.

You'll be reading stored order, not the designed page. Run this check on the exact file you will upload.

1. Export in that text-based format.
2. Open the file and select and copy text from the contact block, each job, education, and skills.
3. Confirm your name, email, and phone appear in that copied text, and that they sit in the body, not only in a header or footer.
4. Confirm the headings survived, and that one date style survived.
5. If the stored order looks wrong, paste the copy into a plain-text editor and read it from top to bottom.

A useful paste can run contact, then the summary, then each role, then education, then skills. If a skill list pops up between two jobs, the columns scrambled the read, and you'll have to fix the layout and export again rather than hope a new filename sorts the lines, which it won't, because a rename never touches reading order. Renaming the file won't reorder the text.

Some people run an ATS checker after that, to see which sections, dates, and keywords were read. Those scores are product outputs. They're not an independent pass standard.

What a clean format will not decide

Parseable formatting doesn't guarantee a correct parse, an interview, a job, a salary, or a visa result. Format so the text can be read in order. Don't treat that as an outcome.

Sources conflict on auto-rejection. A 2026 roundup from Book My Job Interview cites Ashby 2026: 92% of surveyed recruiters say their ATS does not auto-reject resumes. Don't pick a rate from either side. Vendor pages claim the opposite and tie rejection to formatting gaps or keyword scores before a person reviews the file. Don't treat a checker score as a cutoff.

Systems differ. A comment about one platform isn't a formatting rule for every portal. Keyword repetition isn't a tactic. These sources give no required keyword count.

A recruiter still has to want the page once the text lands in order.

FAQ

Is PDF or DOCX always the correct upload?

No. Follow the posting. The text has to be selectable and copyable.

If the posting is silent, guides still disagree. Some default to DOCX unless PDF is requested. Another treats a clean single-column text-based PDF as fine on many modern systems, with DOCX safer for older portals or an explicit Word request. Neither extension repairs a scrambled layout.

Does an ATS auto-reject a resume that fails a score?

Checker scores aren't an independent pass standard, and sources conflict on auto-rejection. A 2026 roundup cites Ashby 2026 for the claim that 92% of surveyed recruiters say their ATS does not auto-reject, while vendor claims say formatting or keyword scores cause automatic rejection.

Don't pick a rate, and don't treat a match score as the portal's rule.

Do columns, tables, headers, or icons fail on every system?

No. Practitioner guides flag them because they often scramble or drop text that is still in the file, and they don't fail on every system. One checklist allows a simple two-column. Single-column remains the safer default.

The bottom line

On the next upload, use a single-column body, standard headings, plain paragraphs and bullets instead of tables, contact details in the body of page one, one consistent date style with the month spelled when you can, text you can select, and a text-based file the posting accepts.

A human still has to want to read it.

Copy the contact line and one job into a plain-text editor before you submit. If that paste is scrambled, fix the layout and export again. Send the file only after the stored text matches the order you intended.