PDF or Word: which file to upload
PDF by default, two real exceptions
Upload a PDF unless you have a specific reason not to. A PDF looks the same on every screen, preserves your formatting through the upload, and is what most people expect a finished resume to look like. The exceptions are narrow: an employer whose own system explicitly asks for a Word file, almost always because someone downstream plans to edit or reformat it, and a very old or poorly built applicant tracking system that parses Word documents more reliably than PDFs built with heavy graphic design. Outside those two cases, the format debate is a distraction from what actually matters, which is what the file contains once tailored for the job, covered in tailoring a resume without rewriting it.
A real instance of the first exception: a marketing agency's application form states directly, in the field description itself, "Word document preferred so our team can add interview notes inline." That is not a stylistic preference to weigh, it is an instruction, and it is worth following exactly as written rather than assuming your usual PDF is close enough.
Why the panic over format is mostly misplaced
Resume upload was one of the fields present on every single one of the twenty real job applications measured for this site, across seven different companies, alongside five other fields that showed up every time; see the six fields you fill in every single time for the full list. Being universal also means the resume upload has been solved thousands of times over by every applicant tracking system in wide use, and none of the major ones choke on a standard PDF produced by Word, Google Docs, or Pages. The format question feels bigger than it is because it is the one part of the resume decision with a clean binary answer, PDF or Word, and binary questions are easier to obsess over than the harder question of what the bullets actually say.
Where PDFs actually go wrong
The real risk with a PDF is not the format itself, it is how it was built. A resume designed in a heavy visual template, multiple columns, icons standing in for section headers, text boxes instead of a normal text flow, can parse into a garbled mess when a system extracts the text for search and filtering, even though it looks perfect to a human eye. If your resume uses a single-column layout with standard headers, this risk is close to zero. If it uses a two-column design with a sidebar for skills, it is worth testing: copy the text out of your own PDF and paste it into a plain text file. If the result reads in a sensible order, the file is fine. If it reads as a scrambled mix of the sidebar and main column, an applicant tracking system is likely seeing the same scramble.
When Word is genuinely the better choice
Some employers, more often for roles that involve writing or editing as part of the job, ask explicitly for a Word file so a recruiter or hiring manager can leave comments or make a light edit before passing it along internally. When a posting or an application form states a format requirement directly, follow it exactly rather than defaulting to your usual PDF. Application forms tend to be knowable in advance rather than a guess; see what ATS application forms actually ask for for how to read a form's requirements before you start filling it in. Outside of an explicit instruction, there is no upside to sending an editable file: content can shift unintentionally, and you lose control over exactly how your resume looks on the other end.
What actually happens when a system reads your file
An applicant tracking system does not "read" a resume the way a person does. It extracts raw text from the file, often to autofill fields like your most recent employer or your skills list, and separately stores the file itself for a human to open later. The autofill step is where badly built PDFs cause visible problems: a two-column layout can extract with the right sidebar's contents interleaved mid-sentence into the left column's text, so a system trying to guess your most recent job title from that jumble autofills something wrong, and you catch it, or do not, on the next screen of the form. This is a real but narrow risk, and it is a formatting risk, not a PDF-versus-Word risk, since a badly built Word file with the same layout problems extracts just as badly.
File size rarely matters, until it does
Most upload fields accept files well into the tens of megabytes, far more than a text-based resume will ever need, so a standard one- or two-page PDF exported normally is never going to hit a size limit. The exception is a resume exported at high resolution from a design tool with an embedded photo or heavy background graphic, which can balloon a simple document into several megabytes and occasionally trip an upload limit on an older system. If your file is anywhere near ten megabytes, something other than text is in it, and that is worth checking regardless of the size limit, since a resume that is mostly image data is also the resume most likely to extract as gibberish in the scenario above.
File naming, a smaller decision with a real answer
Name the file with your name and nothing cryptic: "FirstName_LastName_Resume.pdf" is enough. Skip the version numbers, skip the company name in the filename unless you are deliberately tailoring per company, and skip anything that only made sense to you in the moment you saved it. A resume upload sits alongside a handful of other fields nearly every application asks for the same way every time, and it is worth getting each of those small, repeatable decisions, file name included, right once rather than re-deciding them under pressure at eleven at night.
iapplyai.app prepares the file for you as part of a complete application, tailored resume included, once it scores a live posting as a real match against your real resume. The first two complete applications are free, then it is a fixed term pass that expires on its own, with no automatic renewal. What a pass costs.
