Pages Resume Template: Apple's Built-Ins Reviewed for ATS

What Pages Is and Why It Matters for ATS Applications

Pages is Apple's free word processor, bundled at no charge with every Mac, iPhone, and iPad sold since the macOS Mavericks era. It also runs in any browser through iCloud.com, which means Windows and ChromeOS users can edit Pages files without owning Apple hardware. Pages 14, the version shipping on macOS Sonoma and later, includes a Template Chooser that opens automatically when you create a new document. The Resumes category in the chooser lists a curated set of templates Apple maintains directly, plus the Curriculum Vitae template tucked under the Stationery category.

None of that is the problem. Pages is a capable, modern word processor with excellent typography, real-time collaboration, and a clean editing surface. The problem is the gap between how Pages renders on a Mac and how an ATS parser consumes the exported file. Recruiters never open your .pages document. They open whatever PDF or DOCX the ATS produced after parsing the file you uploaded. That parsed output is what determines whether your name, employer, and skills land in the right database fields.

The good news is that Pages can produce a perfectly ATS-safe resume PDF. You just need to pick the right starting template, strip the parts that look great but parse badly, and use the correct export path. That is the entire job, and the rest of this guide is how to do it.

The .pages Format Problem (and Why Uploading One Is a Rejection)

The native Pages file is not a single document. It is a ZIP bundle that contains an XML representation of the document, embedded fonts, image assets, and a preview rendering. When you click File and Save in Pages, the operating system writes this entire bundle to disk and labels it with the .pages extension. macOS treats it as a single icon for convenience, but on the file system it is a folder.

ATS parsers do not know what to do with this. The ATS upload flow expects one of a short list of file types that its parser libraries can handle, typically .docx, .pdf, .doc, .txt, .rtf, and sometimes .html. The .pages format appears in none of these lists. We have tested uploads to Workday, Greenhouse, Lever, iCIMS, Taleo, Bullhorn, SmartRecruiters, JazzHR, and BambooHR. In every case, one of three things happens when you submit a .pages file:

• The file picker rejects the file outright with an "unsupported file type" error before the upload completes.
• The upload completes but the parser produces an empty profile, leaving Work Experience, Education, and Skills fields blank. Most ATS show the candidate as incomplete and never route them to a recruiter.
• The parser extracts the preview PNG embedded in the bundle and treats your resume as an image, which produces zero readable text and a blank profile.

None of those outcomes are recoverable from the recruiter side. Recruiters do not download your file, notice it failed to parse, and helpfully convert it themselves. They search the ATS for keywords. If your profile has no keywords because the parser produced nothing, your application is invisible.

Built-In Resume Templates Reviewed: Which Ones Parse, Which Ones Fail

Pages 14 ships with a curated Resumes category in the Template Chooser. The exact list shifts slightly between point releases, but the templates below have been stable for several versions. We graded each one on parse safety after a clean PDF export to a Greenhouse and Workday test environment, plus visual cleanliness on a final recruiter view.

Two takeaways are stable across every test we run. First, any Pages template with a sidebar is dangerous, regardless of how clean the typography looks. Second, the simpler the template, the better the parse rate. Classic, Professional, Business, and Curriculum Vitae are the four built-ins we recommend for actual job applications. Modern is workable after light modification. The rest are visual portfolio pieces that look beautiful when emailed directly to a hiring manager but should never go through an ATS upload.

Two-Column Templates: Exactly Why They Break

Pages renders two-column layouts using floating text frames rather than true newspaper columns. To a designer, this is convenient. You can drag a frame, resize it, and the surrounding content reflows. To an ATS parser, this is a nightmare. Parsers consume the document by walking the underlying XML in reading order, and Pages writes the floating frames as separate objects whose position is described in coordinates rather than reading order. Different parsers handle this differently, but the typical outcomes are predictable.

If you love the look of a two-column resume, build it for your personal site or LinkedIn portfolio and use a separate, plain single-column PDF for ATS applications. The "design portfolio plus boring ATS doc" two-file strategy is what most senior designers and product managers we have interviewed actually use.

Export Workflow Step-by-Step: From Pages to ATS-Safe PDF

Once you have picked a safe template and written your content, the export step is what determines whether the ATS sees a parseable text document or a flat image. Pages offers several export paths, and they are not equivalent. Follow this sequence.

If the job application asks specifically for a Word document, use File > Export To > Word (.docx). Pages will produce a .docx file that opens cleanly in Word and Google Docs. The Word export is usually fine for ATS parsing as long as you avoided sidebar layouts in your Pages source. If your Pages document used a sidebar, the Word export preserves the sidebar as a floating text box, which Word handles but which most ATS still parse poorly.

Pages Smart Fields and Why They Can Break Parsing

Pages includes a feature called Smart Fields, which are auto-updating fields for dates, page numbers, document title, file path, and author name. Apple's intent is to keep documents tidy when you reuse them. If you insert a Date Smart Field into a resume template, the date updates every time you reopen the file. That is harmless during editing but causes two specific problems for resumes.

First, several built-in resume templates use a Date Smart Field in the header that displays today's date. When you export to PDF, the PDF freezes today's date into the document. If you open the PDF a week later and resubmit it, the recruiter sees a date that is a week old, which makes the application look stale. Worse, some recruiters interpret an old date as evidence the candidate is mass-applying with the same file.

Second, Pages exports Smart Fields to PDF as live text in the visible layer but sometimes encodes the underlying field type into the document metadata. We have seen one parser version (an older Taleo build) read the field metadata as a structured property and discard the surrounding text. The simple fix: select the Date field in your template, delete it, and type a static date if you want one displayed at all. Most resumes do not need a date in the header. The application timestamp lives in the ATS regardless.

The Author Smart Field has a separate problem. Pages populates the author name from the iCloud account or the macOS Contacts card. If you are using a partner's or family member's Mac, the author field can carry their name into the exported document metadata. Some ATS read document metadata and surface the original author to the recruiter, which can cause confusion. Set the document author explicitly via File > Advanced > Change Document Author Name before exporting.

Filled Example: A Pages Resume That Survives Workday and Greenhouse

To make the rules above concrete, here is a worked example of a Pages resume built from the Classic template, exported to PDF, and successfully parsed through both Workday and Greenhouse test instances. The candidate is fictional. The structure, choices, and parser outcomes are real.

The same content, dropped into Pages's Contemporary template with the Skills section moved to the sidebar, produced a Workday parse with the Skills section completely empty and a Greenhouse parse that interleaved bullet points across the two employers. Same words, same candidate, two very different outcomes, driven entirely by template choice.

Pages vs Google Docs vs Word for Mac: Which One to Use

Mac users have three serious word processors to choose from. Pages is free and beautiful. Google Docs is collaborative and browser-based. Microsoft Word for Mac is the universal standard. The right choice depends on what you value and where the resume is going.

Our recommendation for most Mac users: write in whichever app you find pleasant to use, then export to PDF for the upload. If a specific application form requires a Word document, do the work in Word or Google Docs rather than fighting a Pages-to-.docx conversion on a complex template. The conversion is usually fine, but "usually" is not the bar for a job application you cannot retake.

Mac-Specific Font Choices and the Substitution Trap

Pages defaults to fonts that ship with macOS and look beautiful on Retina displays. Several of those fonts do not exist outside Apple devices, which creates a subtle but real problem when your resume travels through systems that re-render it. The most common offender is San Francisco, Apple's system typeface. San Francisco is technically licensed only for use within Apple software and on Apple hardware. When Pages exports a PDF, San Francisco is embedded as a subset font and renders correctly. But if the ATS produces a re-rendered preview for the recruiter, or if a recruiter opens your .docx in Word on Windows, the system substitutes a fallback typeface that often does not match the spacing San Francisco assumes.

The same trap applies, in milder form, to Helvetica Neue, which Apple ships in many weights but which exists on Windows in fewer variants. Bold and italic Helvetica Neue weights frequently fall back to plain Helvetica on Windows, which makes section headers look thinner than intended.

For body text, 10.5 to 11.5 point on most of these fonts is the sweet spot. Anything below 10 point parses poorly because the rendered glyph quality drops at small sizes in many PDF tools. Anything above 12 point pushes a one-page resume into two pages without adding information. See our deep guide to ATS-friendly resume fonts and styles for the full size and weight recommendations by industry.

iPad Pages: When It Works, When to Switch to a Mac

Pages on iPad is real Pages, not a stripped-down viewer. You can open the same Template Chooser, edit the same documents, and export to PDF or Word with the same options. For drafting and minor edits, iPad Pages is excellent, especially with a hardware keyboard and Stage Manager on iPadOS 18.

Where iPad Pages falls short is in three specific situations that affect resumes. First, font selection on iPad is limited to fonts that ship with iPadOS plus any custom fonts you have installed through an app like Creative Cloud or AnyFont. Several Mac fonts simply do not exist on iPad, so a resume designed on iPad and finished on a Mac will reflow when you open it on the desktop. Second, the PDF export on iPad uses the iOS PDF rendering pipeline, which produces excellent results for text but occasionally rasterizes complex graphics that the macOS path renders as vectors. For resumes without graphics, this never matters; for templates with photo blocks or decorative shapes, it can. Third, version history on iPad is accessible only when the document is stored in iCloud. If you keep your resume in a third-party cloud (Dropbox, Box, Google Drive) and want to roll back a change, you must open the document on a Mac.

For a draft commute or a quick typo fix on the way to an interview, iPad Pages is more than enough. For the final export that you upload to a job application, do the export from a Mac if you have one available. The two PDFs are usually identical, but "usually" is again not the bar.

iCloud Sync and Version History: The Backup You Already Have

Pages documents stored in iCloud are versioned automatically. Every time you stop typing for a few minutes, Pages records a snapshot. You can scrub through the snapshots by opening the document and choosing File > Revert To > Browse All Versions on macOS. This is the same Time Machine-style browser used by other Apple apps. It is also the cheapest, easiest way to maintain a history of resume edits without keeping ten files named "resume-final-final-v2.pages" on your desktop.

Two practical uses for the version history are worth knowing. The first is recovering a deleted bullet point. If you cut a strong bullet about a project that suddenly becomes relevant a month later, the version history almost always has it. The second is comparing a resume from before and after a major rewrite, which can surface phrasings you preferred but forgot. For both uses, set your active resume to live in iCloud Drive rather than in Documents on your local Mac, and Pages will keep the version history automatically.

One caveat: iCloud version history applies to the .pages source file, not to exported PDFs. If you want to keep a record of each PDF you actually submitted to an employer, save exports into a dated subfolder. The .pages file is the source of truth. The PDF is what the employer received. Both are worth keeping.

Common Pages Resume Mistakes We See Repeatedly

Frequently Asked Questions