Every rejected application raises the same quiet suspicion: maybe the file itself never made it through. Applicant tracking software reads your resume before a human does, and the file format you choose decides how much of it survives that first pass. This guide walks through the cv file types ats systems handle well, the ones that quietly break, and a two-minute test that tells you which camp your resume falls into.
Why the file format matters at all
An ATS does not look at your resume the way you do. It opens the file, pulls out the raw text, and tries to sort that text into fields: name, work history, skills, dates. When the format cooperates, your bullet points land where they should. When it does not, your job titles scatter, your dates vanish, and a recruiter sees a garbled mess or nothing at all.
So the real question behind "which file format ats accepts" is less about a magic extension and more about whether the software can extract clean, ordered text. Two files with the same extension can behave completely differently depending on how they were made.
The safe default: .docx
If you want the least risk, save your resume as a Microsoft Word .docx file. It is the format ATS platforms have been built around for two decades, and parsing engines are tuned for it. Text stays as text, headings keep their structure, and almost nothing gets lost in translation.
A few reasons .docx stays reliable:
- The text is always selectable and machine-readable, never an image.
- Section structure survives, so "Experience" and "Education" get recognized as sections.
- Older and cheaper ATS tools, which are still common, parse it without complaint.
The old .doc format (pre-2007 Word) works too, but there is no reason to reach for it anymore. Stick with .docx.
PDF: fine now, with one big condition
Here is the myth worth killing: PDF does not automatically fail an ATS. Modern parsers handle PDFs well, and most large employers use systems that read them without issue. The condition is that it must be a real text PDF, not an image.
There are two kinds of PDF that look identical on screen:
- A text-based PDF, exported directly from Word, Google Docs, or a resume builder. The text is embedded and selectable.
- An image-based PDF, usually a scan or a screenshot saved as PDF. It is just a picture of your resume, with no readable text underneath.
An ATS can read the first kind. The second kind gives it nothing unless the system runs OCR, and you should never gamble on that.
If you can open your PDF, click and drag to highlight a sentence, and actually select the words, it is a text PDF. If your cursor selects the whole page as one block or nothing at all, it is an image, and an ATS is effectively blind to it.
Design-heavy PDFs from tools like Canva carry a second risk: text tucked into columns, text boxes, or graphics can get read out of order even when it is technically selectable. A clean single-column layout parses far more predictably.
Formats to avoid
Some formats create problems no matter how good your content is:
- .pages (Apple Pages). Most ATS platforms cannot open it at all. Export to .docx or PDF before you submit.
- .txt (plain text). The text is perfectly readable, but you lose every bit of formatting, so bold, bullets, and section breaks disappear. Fine as a last-resort paste, poor as an upload.
- .rtf (rich text). Parsing is inconsistent across systems. Sometimes it works, sometimes it drops formatting in strange ways. Not worth the coin flip.
- Image files (.jpg, .png) and scanned documents. These have no extractable text at all. Avoid entirely.
- Google Docs share links. A link is not a file. The recruiter may hit a permission wall, and the ATS certainly cannot ingest a URL. Always download and upload the actual document.
Let the application form make the call
Before you overthink it, read the upload button. If the job form says "PDF only," send a text PDF. If it says "Word documents only," send .docx. The form is telling you what the system on the other end expects, and matching it is the safest move you can make.
Many application forms also give you two ways in: an upload field and a paste field. Watch how they behave.
- Upload fields take your file and parse it. Format matters most here.
- Paste fields ask you to drop your resume text into a box. Formatting mostly strips away, so review the pasted result and fix anything that collapsed, especially bullet lists and spacing.
When a form offers both, upload the file for structure and, if there is a separate plain-text box, paste a clean version there too.
A small detail people forget: name the file plainly. Something like Firstname-Lastname-Resume.docx reads well to both the software and the human who eventually downloads it. Skip spaces, version numbers, and "final-FINAL-v3" clutter.
The copy-paste test that settles it
You do not have to guess whether your file parses. Run this in under two minutes:
- Open your finished resume, whether PDF or Word.
- Select all the text and copy it.
- Paste it into a blank plain-text editor, such as Notepad or TextEdit in plain mode.
- Read what came out.
If the text appears in a sensible order, with your name up top and your jobs in sequence, an ATS will likely see the same thing. If words are jumbled, dates float away from their roles, or whole sections come out blank, that is exactly what the parser gets, and you need to fix the layout or switch formats.
Some resume tools, including Postulit, generate their exports as clean text-based files specifically so this test passes on the first try. But the test works on any file from any source, so run it regardless of where your resume came from.
The takeaway
Default to .docx when you are unsure, use a text-based PDF when the form asks for PDF or when you care about pixel-perfect layout, and skip .pages, .rtf, images, and share links entirely. Then run the copy-paste test once before you submit. If the text pastes out clean and in order, your file will read fine, and you can go back to worrying about the parts of the application that actually deserve your attention.