One-page or two-page resume? What decides it in 2026

One page if your whole work history fits on one. Two if cutting it to one page would mean deleting a job you actually held. That is the thing it depends on, and everything else people argue about — whether recruiters are busy, whether brevity signals confidence — sits downstream of it.

The reason is mechanical. An applicant tracking system does not measure your resume; it takes your employment history apart and stores the pieces, and the pieces it cares about most are dates. Delete a role to save a page and you have not tightened your resume. You have edited a fact.

Why the dates decide it and the pages do not

Workday's administrator documentation describes the step in one sentence — "Resume parsing populates fields from a resume" — and its Recruiting for Administrators manual names what gets populated: personal and contact information, work experience, education and languages. HiredScore, the screening layer Workday sells on top of Recruiting, goes further and "calculates employment gaps and time in position" from that same parsed history.

Both of those are arithmetic on your dates. Take a Senior Software Engineer with eleven years across four employers, who trims the 2015–2018 job to land on a single page. The resume now looks disciplined and reads, to the software, as a career with a three-year hole in the middle and three fewer years of countable experience. Nobody made a judgement about that candidate. A subtraction happened.

This is the one formatting decision on a resume that can change a fact about you. Every other bad choice — a two-column layout, a photo, a name stranded in a header — costs you legibility, and legibility is recoverable: a recruiter who wants your name can open the file and read it. A deleted job is not in the file at all. That is why "make it fit on one page" is the most expensive piece of resume advice still in wide circulation, and why the fix is to let the page count follow the history instead of the other way round.

How much experience the job is actually asking for

O*NET sorts every occupation into a Job Zone, and inside each zone sits a Specific Vocational Preparation range — SVP, the amount of time it takes to learn the work to average competence. Software Developers (15-1252.00) is Job Zone Four, "Considerable Preparation Needed," with an SVP range of 7.0 to under 8.0. The scale attaches a real span of time to each level: SVP 7 is "Over 2 years up to and including 4 years," and SVP 8 is "Over 4 years up to and including 10 years."

Years of preparation in each O*NET SVP level

The upper bound of each level's time span. Software Developers sits at SVP 7.0 to under 8.0, so the classification's band for the occupation closes at four years of specific preparation.

SVP 5 — over 6 months, up to 1 year		1 yrs
SVP 6 — over 1 year, up to 2 years		2 yrs
SVP 7 — over 2 years, up to 4 years		4 yrsSoftware Developers
SVP 8 — over 4 years, up to 10 years		10 yrs

Read that range carefully, because it is the part people get wrong. "7.0 to under 8.0" means the band closes before SVP 8 opens, so O*NET's ceiling for a software developer is four years of specific preparation — not the ten years that level 8 would allow, and not the open-ended level 9 above it. Everything after year four is no longer preparation. It is history: what you owned, how large it was, who else was on it. Scope like that lives in the last two roles, and it almost never needs a fifth job carrying six bullets.

So a Senior Software Engineer eight years in has a legitimate two-page resume, and a Senior Software Engineer twenty-two years in usually has a two-page resume too, just with the first eleven years compressed to a line apiece. The page count stops growing. The detail per role does the shrinking.

Education takes up less room than most drafts give it, for the same reason. In O*NET's respondent survey for the occupation, on a profile updated in 2026, 85% said the job requires a bachelor's degree, 5% a master's and 5% a two-year degree — a distribution that flat means the degree is a checkbox, not a differentiator, and a checkbox needs one line: school, degree, year. Three lines of honours and relevant coursework on the resume of an eleven-year engineer are three lines that could have held an employer.

The two ends of this, in the published numbers

Both columns are 2025 figures from the BLS Occupational Outlook Handbook, whose pages for both occupations were last updated in August 2026. Two rows in that table matter for page length. The first is that BLS publishes no occupation called "copywriter" — writers and authors is the nearest published category, so a Junior Copywriter should read it as the neighbourhood rather than as their job description. The second is the row that says "None" twice: neither occupation treats prior experience in a related job as typical for entry. A junior copywriter's single page is not a shortfall waiting to be padded out. It is the shape the occupation expects.

O*NET puts the 2025 median for software developers at $135,980 a year, against the Handbook's $134,040. That is not two sources disagreeing. Both are reporting BLS wage data for 2025; O*NET is reporting software developers on their own, and the Handbook is reporting developers, QA analysts and testers as one combined group.

So — one page or two?

One page for anyone with fewer than about four years of full-time history, which is where O*NET's SVP 7 band closes. That is the Junior Copywriter with two agencies and an internship behind them, and it stays one page even when the work is good. Two pages once the roles that prove your seniority cannot all appear, with their dates, on one. Three pages is a portfolio or an academic CV, and if you are sending one of those to a corporate opening, length is not the problem you have.

Which one you are, by what is on the page

The test is whether page two carries employment history or spillover from page one.

	One page	Two pages
Full-time history	Up to about four years — the top of O*NET's SVP 7 band	More than that, with real roles behind it
Example title	Junior Copywriter	Senior Software Engineer, eight years in
What page two would hold	Coursework, a second projects section, restated skills	Employers and dates that would otherwise vanish
Bullets on the oldest role	None — it is one line	One line, or none
Risk of getting it wrong	Padding a thin page with filler	A gap the parser computes on your behalf

What length does and does not do inside the ATS

Nothing in the published parsing documentation is about length. Greenhouse's list of causes for an unsuccessful parse names a 2.5MB file size ceiling, resumes with spaces between the letters, graphics and photos, image-based files, tables, headers and footers, columned layouts, and sections formatted inconsistently. A plain two-page document appears nowhere on that list and comes nowhere near 2.5MB. Workday runs the same way — "For best results, use resumes that don't have images or image-based styles" — and warns that "Resume parsing results can vary based on resume format and order of words."

Format and word order. Not page count.

There is a second reason length matters less than the design conversation implies. HiredScore "presents candidates' parsed, or smart, resumes in the same format to ensure that you can consistently and easily find relevant information," from files supplied as DOC, DOCX, PDF, RTF or TXT. On that setup, the first thing a recruiter sees when they open a candidate is a normalised view built out of extracted fields, laid out identically for every applicant in the pile. Your two pages and someone else's one page arrive looking the same. What differs between them is how much was successfully extracted.

Which turns the usual advice inside out. A one-page resume in a two-column template with the contact details in a header is a worse submission than a two-page single-column one, every time, because the first is on Greenhouse's failure list and the second is not on anybody's.

The Junior Copywriter is the person most exposed to that trade, because the templates marketed to creative applicants are the ones built out of columns, tinted sidebars and a headshot. Squeezing a short history into a designed single page is how a candidate with genuinely nothing to hide ends up with a candidate record whose name field is empty. If the choice is between a decorated one-pager and a plain one-pager, take the plain one; the design was never the thing being evaluated.

What none of this data tells you

None of these sources measures whether a recruiter reads the second page. BLS counts employment and wages, O*NET describes the preparation an occupation takes, and the vendor documentation describes what software extracts from a file — not one of them observes a hiring decision, and none of them says a page count changed one. The "recruiters spend six seconds on a resume" figure you have met a hundred times appears in none of them, and no statistical agency publishes it, which is why it is not used as evidence anywhere in this post.

What the sources do support is narrower and more useful. The systems standing in front of the recruiter store dates, compute gaps and totals from them, and publish no length rule at all. That is enough to settle the question without anyone having to know what happens in the sixth second.

It also means the honest version of the advice has a limit to it. A Senior Software Engineer whose second page is real employment history is safe from everything the documentation describes, and still exposed to a hiring manager who simply prefers one page and will never write that preference down anywhere you can read it. You cannot design around a preference nobody publishes. You can make sure that when the preference does not exist, the eleven years are all still countable.

Where the cut goes when you need one

Say you are a Senior Software Engineer at eleven years and the draft has run to two and a half pages. The cut is never a job. It is everything on the page that is not a job, in this order:

• Bullets on roles older than about ten years. Title, employer, dates, one line. Nothing that old is being read for detail, and the dates still count toward your total.
• The skills section that repeats the bullets. Keep the named tools and languages; delete the adjectives and the proficiency bars.
• The summary paragraph, if it restates the current role. Three lines at most, and only if it says something the roles themselves do not.
• Coursework, GPA and graduation year, once you are two employers past graduation. A Junior Copywriter keeps all three. The Senior Software Engineer gains nothing from any of them.
• The second and third bullet of any role where they restate the first. Most resumes lose half a page here without losing one fact.

Work down that list and the file usually settles at two clean pages with every employer and every date intact — which is the outcome you wanted before anyone started counting sheets of paper.

What to do this week

Write down, on paper, the start and end month of every job you have held. Compare that list against what is on your resume right now. If a job is missing, put it back, even if it pushes you onto a second page: that is the whole argument of this post, and it is the only edit here that changes what a filter computes about you.

Then set the oldest third of your roles to one line each and see where the page break falls. If it falls in the middle of a role, move the break, not the role.

Last, fix the format before you worry about the length again. One column, contact details in the body of the document, no header, no photo, exported as a real PDF or DOCX rather than a scan. If you would rather not retype those same employers and dates into every application form afterwards, HeroApply fills the application from this resume — out of the same fields the parser pulled from it.