Skip to content
LSI Resume
May 12, 2026·7 min read

How Workday actually parses your resume (and the 3 things that break it)

A walkthrough of Workday's resume-parsing pipeline — how it extracts text, identifies sections, and matches keywords against the job requisition. Plus the three formatting traps that cause Workday to drop content most reliably.

#workday#ats-mechanics#resume-formatting

Workday is the largest enterprise ATS by deployed seats. Roughly half the Fortune 500 runs a Workday HCM, and most of them run Workday's own recruiting module on top of it. If you've applied to a job at a company with more than 10,000 employees in the last three years, your resume has almost certainly been read by Workday before any human touched it.

Workday's parser is not a black box. We can see its behavior empirically by submitting controlled test resumes through Workday recruiter sandboxes and comparing the parsed output against the source PDF. This post is what we've learned doing exactly that — what Workday extracts, what it drops, and the three formatting choices that cause it to drop the most content.

The pipeline

Workday's resume-parsing flow runs in three stages: extract, structure, match. Each stage has its own failure modes.

Extract. Workday converts the PDF to plain text using Apache PDFBox under the hood. The extraction respects positional information: each glyph in the source has an (x, y) coordinate on the page, and the parser uses those coordinates to reconstruct reading order. This is where layout matters most — a multi-column resume looks fine to a human reading column-by-column, but the parser reads strictly top-to-bottom across the page, interleaving the columns into nonsense.

Structure. Once the text is extracted, Workday identifies sections by matching against an internal regex of standard headers — "Experience" / "Work Experience" / "Professional Experience" / "Employment History" all match; "Where I've Made Impact" does not. Each recognized section is then parsed for entities: job titles, employers, dates, schools, degrees, contact info. The entity extractor is fairly permissive on title and employer (almost anything works) but strict on dates — a bare year ("2023") parses, but creative formats ("Spring '23", "Q1 of last year") often don't.

Match. Finally Workday scores the resume against the job requisition by computing keyword overlap with the JD's required and preferred skills. The match score isn't a hard cutoff — Workday surfaces all candidates regardless — but it determines the rank order, which determines who the recruiter sees first.

What Workday actually weights

Across roles and seniorities, three signals dominate Workday's ranking:

  1. Keyword overlap with the requisition's required skills. Workday allows the recruiter to enter required and preferred skills when posting. A resume that mentions every required skill at least once will outrank one that misses any of them, regardless of seniority. The match is approximately keyword-presence (it does some stemming) — synonyms don't count, so "led" and "managed" are distinct terms.
  2. Recency of relevant experience. Workday weights recent experience more heavily than older experience. A bullet about leading a team in 2024 outscores the same bullet from 2018, even when the role was the same. This is why "executive summary" sections that lead with current achievements do measurably better in Workday than ones that lead with career history.
  3. Title progression. Workday infers seniority from your title sequence. A resume showing "Engineer → Senior Engineer → Staff Engineer" reads as a senior IC; one showing the same titles in reverse order reads as someone in decline. Workday doesn't surface the seniority inference directly, but it shows up in candidate rank for senior reqs.

What Workday explicitly does NOT use, contrary to common belief: cover-letter quality, GPA, school prestige (unless the recruiter filters on it manually), or the visual design of the resume. Visual design only matters insofar as it affects whether the parser can extract text at all.

The three things that break Workday parsing

After reviewing several hundred resumes through both Workday and our free analyzer, three formatting choices account for roughly 80% of the cases where good content doesn't survive parsing.

1. Multi-column layouts (the biggest single failure)

Workday's parser reads strictly left-to-right, top-to-bottom across the page. A two-column resume — even one that's beautifully designed for human readers — produces interleaved nonsense. The first line of column A becomes the first parsed line, then the first line of column B, then the second of A, then the second of B. By the time the parser reaches the bottom of page 1, the extracted text bears no resemblance to what you wrote.

The visible symptom: dates and bullet content end up in the wrong roles, employer names appear inside skill sections, the entire structure of the resume falls apart.

The fix. Single column. Always single column. If you have a sidebar with skills, dates or contact info, restructure the layout to put that content in a header row above the body. The aesthetic loss is small; the parser-survival gain is enormous.

2. Tables (especially for skills)

The convention of laying out skills as a table — Languages | Python, Go, Rust in one row, Frameworks | React, Next.js in the next — visually compact and hard to parse. PDFBox flattens tables into space-separated rows, which means "Languages Python, Go, Rust Frameworks React, Next.js" becomes one continuous string. The category labels disappear; the categorization is lost.

Worse, when Workday's section parser then tries to identify the Skills section header and content, it gets confused by the merged structure and may classify the whole thing as one giant skill ("Languages Python Go Rust Frameworks..."), which then mismatches against every required skill.

The fix. Comma-separated lists with category labels as plain text:

Languages: Python, Go, Rust, TypeScript
Frameworks: React, Next.js, FastAPI, Django
Infrastructure: AWS, Kubernetes, Terraform, Postgres

Visually slightly less compact, but parses cleanly into individually-recognized skills.

3. Contact info in the page header or footer

Some PDF authoring tools (especially Word's "modern" templates) put contact info in the page header — the area above the top margin that repeats on every page. Workday's parser strips header/footer regions before extracting body text. This means email and phone go missing entirely from the parsed output, even though they're visually obvious to a human reader.

The visible symptom: your Workday application has empty email/phone fields even though you submitted a resume with both. The recruiter can't reach you without manually opening the PDF.

The fix. Put email, phone and location in the body of the first page — typically in a contact row directly under your name. Don't use the document's header area for anything you want extracted.

How to test if your resume survives Workday

The free LSI Resume Analyzer simulates Workday's parsing failures in your browser. Drop your PDF, and you'll see the per-engine cleanliness score plus the specific structural failures (multi-column collapse, table flattening, header drops) that would happen in Workday on your file. The analysis runs locally — your resume doesn't leave your device.

If you'd rather test against a real Workday instance, the technique is:

  1. Apply to a Workday-hosted job at a company you don't actually want to work for
  2. Note what fields auto-populate from your resume
  3. Look for: missing contact info (header issue), garbled work history (multi-column issue), Skills section showing as one giant string (table issue)

The analyzer approach is faster and doesn't burn applications. The real-Workday test is the gold standard if you want to verify a specific edge case.

What about Workday's "Skills Cloud" matching?

Workday introduced an ML-based skills matching layer in 2022 (called Skills Cloud) that does some synonym expansion and skill clustering — "React" and "Next.js" cluster as related, "Kubernetes" and "container orchestration" map together. This is real and meaningful.

But it sits on top of the keyword extractor, not in place of it. If the keyword extractor never sees "Kubernetes" because it was inside a table that flattened, Skills Cloud has nothing to cluster. The fundamentals — clean layout, no tables, contact info in body — still determine whether the rest of Workday's intelligence has anything to work with.

Quick checklist for Workday survival

  • Single column layout, top-to-bottom reading order
  • Skills as comma-separated lists, never tables
  • Contact info in the body of page 1, never in the document header
  • Standard section headers ("Experience", not "Where I've Made Impact")
  • Dates as standard formats: "Jan 2023 — Present", "2020 — 2023", "01/2023 — 04/2025"
  • No images-only PDFs (verify by copy-pasting text from your PDF in any reader)
  • Keep the resume to 2 pages unless you're explicitly senior (3 acceptable for staff/principal/director)

If you want to know how YOUR specific resume scores across all five major ATS engines including Workday, run the free analyzer. It surfaces every issue with snippet + fix in roughly 4 seconds, in your browser, with no signup.

Test your own resume against everything in this post

The free analyzer runs in your browser, simulates 5 ATS engines, and surfaces every issue with a snippet + fix. No signup, fully private.

Related posts