Updated August 13, 2026

Resume formatting that ATS software can actually parse

ATS formatting is not a taste debate about “modern” versus “traditional.” It is data integrity. The portal has to turn your file into a sequence of characters and, if you are lucky, into fields such as name, dates, and skills. Decorative layout that looks expensive in a portfolio often arrives as scrambled text.

This page is a build guide: how to assemble a file that parsers can read. It is not a promise that every vendor extracts documents the same way, and it is not a claim that a pretty template “beats ATS.” If you want the pipeline explained first, read the companion article on how ATS software reads resumes.

ResumeTune’s free check flags a few text-level format problems after extraction. It does not invent font or precise layout findings when the parser cannot supply them. Use the checks below as the source of truth for what to change in the file itself.

Build for a top-to-bottom reading order

Assume the extractor reads the page like a column of text, not like a poster. One main column, from contact details through experience, education, and skills, is the layout that survives the most systems. Two columns, sidebars, and “skills on the left, story on the right” designs are where job titles get glued to the wrong dates.

You do not have to make the file ugly. You do have to keep important content as real, selectable text in a predictable order. If a human has to hunt visually, the parser is already at a disadvantage.

One column for the body of the resume.
Standard margins; do not shrink type to force a one-page poster.
Role blocks in a stable pattern: title, company, dates, then bullets.

Use headings a filter can recognize

Section titles are how many systems decide what a block of text is. “Experience,” “Work Experience,” “Education,” and “Skills” (or the Spanish equivalents Experiencia, Educación, Competencias) are boring on purpose. Creative labels — “My journey,” “Wins,” “Toolbox” — are clear to a designer and opaque to a heading library.

Put each heading on its own line. Do not hide it inside a colored shape or an image. If the heading is not copyable as text, it may as well not exist for search.

Keep contact details in the body

Email and phone belong in the main document flow, near the top, as normal text. Word headers and footers, and repeating PDF running heads, are often ignored or treated as noise because they appear on every page.

If a checker reports missing contact information, it usually means the extracted text had no email or phone — not that you forgot them on the designed page. Move them out of the header and export again.

Choose a file the portal can extract

DOCX is a structured document format and is often the most predictable for text extraction. A text-based PDF exported from Word or Google Docs is usually fine. A PDF that is a scan, a screenshot, or an export from a design tool with unselectable text is the hard case: there may be no real text layer unless optical character recognition runs, and OCR quality varies.

A practical test: open the file and try to select a sentence in the experience section. If you cannot highlight it, an ATS is unlikely to index it. Paste the whole document into a plain-text editor. If names, dates, and bullets arrive in a jumble, that jumble is a fair preview of extraction.

Prefer DOCX or a selectable-text PDF over a scanned image.
Follow the employer’s format instructions when they specify one.
Do not lock skills inside logos, infographic bars, or icons.

Tables, tabs, and “invisible” layout

Tables used as the page grid are a common failure. Many extractors walk cell by cell and destroy chronological order. The same happens with tab stops and runs of spaces used to fake two columns. The page looks aligned; the text stream does not.

Text boxes and floating frames from design tools have the same problem: visual position is not reading order. If you need a simple two-line header (name on one line, email on the next), use ordinary paragraphs, not a miniature table.

What automated checkers can honestly flag

After a parser extracts text, a rules-based checker can look for signals in that text. ResumeTune’s free pass can warn about very short or very long extracted text, missing email and phone in the extracted string, few recognizable section headings, unusually long lines, and tab or spacing patterns that often come from columns. Page-count warnings run only when page count is reliable. Font consistency and precise “this is a two-column layout” geometry are omitted unless the parser supplies that metadata — and today it does not.

That honesty matters. A site that claims to know your exact font pairing or to simulate Workday’s parser is guessing. Use those claims as marketing, not as a spec for your file.

Fix the file, then re-upload. Editing a score without changing the document does not change what the next employer’s system will extract.

A format checklist before you send

Run this on the actual file you will upload, not on a screenshot of a template.

Select-and-copy works on the body text.
Plain-text paste keeps roles, dates, and bullets in a sensible order.
Headings are standard words on their own lines.
Email or phone appears in the body, not only in a header.
No layout tables, skill bars, or text trapped in images.
The resume is in English or Spanish if you plan to use ResumeTune’s free check.

Where ResumeTune fits

Upload on the homepage for a free technical readability check. Add a job description only when you also want keyword overlap. The format findings describe the extracted text, not a prediction of interviews, and they will not list font or layout issues the parser cannot verify.