Resume Headings: Standard vs Creative Labels in an ATS Parser

TL;DR: Which resume headings should you use? The plain ones: Summary, Work Experience (or Experience), Education and Skills, each on its own line. We ran one resume with seven sets of headings through an open-source parser. Standard labels kept the work history, degree and skills in all six of their files. Creative labels ("My Journey", "Toolbox") lost all three in all six of theirs. Check your own headings before you apply.

What are resume headings, and why does a parser care?

Two different things share the name, and the search results mix them up.

Resume heading (section heading): the label above each block of your resume, such as "Work Experience" or "Education". A parser uses it to decide where a section starts and which field its contents belong to.

Resume header: the block at the top of the page with your name and contact details. It is not a section heading, and in a Word file it should not sit in the page header either (more on that below).

When you upload a resume, an applicant tracking system (ATS) first parses it: it extracts the text and splits it into fields such as name, email, each job and each degree. Recruiters later search and filter those fields. The heading is the signal the parser uses to split the text, so a heading it does not recognise can leave a whole block unfiled.

The parser vendors say this in their own documentation. Textkernel, a resume-parsing vendor, publishes a list of resume quality findings its parser can return. It includes code 413, "Indicates that a WORK HISTORY section was not found", and code 414 for a missing EDUCATION section, and its message for code 151 reads "Every section should have a clear, unambiguous, commonly-used header on a separate line" (Textkernel developer docs). Textkernel also warns that this output should not be read as a sign the parser failed, so treat it as a description of what the parser looks for, not a pass mark.

RChilli, another parsing vendor, is blunter. Its tips for electronic resumes list "Missing headings (e.g. for experience or education block, we cannot define their boundaries)", "Combine heading (e.g. Education/Skill/training etc.)" and "Unusual heading" as problems. Greenhouse, the ATS, includes "Resumes without clear sections and differing formats throughout each section" among the causes of a failed resume parse, after which the file is only attached and someone types your details in by hand.

Which resume headings should you use?

Use the labels a parser expects, and add optional sections only when you have content for them. Textkernel's technical specifications list the sections its parser supports, among them Contact Info, Job Objective, Executive Summary, Qualification Summary, Employment History, Education History, Skills, Licenses and Certifications, and Languages. That list maps neatly onto the headings below.

So what are the five sections of a resume? For most US applications: the contact header, a summary, work experience, education and skills. Certifications, projects and languages are the usual sixth and seventh, and they parse best under those exact words. If you are deciding between a summary and an objective, our objective vs summary guide covers which one fits your career stage, and the skills section guide covers what to put under that heading.

The "Not mapped" column above comes from one open-source parser, not from Workday or Greenhouse. The next section explains what we ran and why the results still matter for commercial systems.

We ran 7 heading sets through an open-source parser

On 13 October 2026 we built one fictional resume (an operations analyst with two jobs, one degree and a skills line) and changed only the headings. Seven label sets, each in three styles (bold capitals, bold title case and regular title case), gave 21 PDF files. We parsed each with the parser from OpenResume, an open-source resume builder, at commit 4f8255a. Its code is public, so you can read exactly why a heading was or was not recognised. We ran it in Node with pdf.js 3.7.107; the only changes were swapping the browser PDF loader for the Node one and stubbing one constant from the app's state store. Exported to plain text with pdftotext, all 21 files read the same apart from the heading lines, so every difference below comes from the labels.

"All 3 fields" means both jobs came out with the right title, company and dates, the degree came out with its school, and the skills line was filed as skills. Across the 21 files, the two standard sets kept 18 of 18 fields. The three synonym sets kept 6 of 27. The two creative sets kept 0 of 18.

"Jobs polluted" is the worst result in the table. With "Academic Background" and "Core Competencies" in title case, the parser did not see them as headings, so it kept reading them as part of the experience section. It returned four jobs instead of two: the extra entries had "Core Competencies" and either "Academic Background" (bold) or "Ohio State University" (regular type) as the company name. A recruiter searching that record sees a candidate with a job at a university and no degree.

Why creative and "safe-sounding" labels failed

The OpenResume parser makes two decisions, and a heading has to pass both. Its source code shows them.

First, is this line a heading? A line counts if it is the only item on the line and is both bold and all capitals. If it is not, a fallback accepts a line of at most two words, starting with a capital letter, that contains a keyword such as "experience", "education", "skill", "project", "summary" or "objective". The project page states that the algorithm "is designed to parse single column resume in English language".

Second, which field does the section feed? Work history is pulled from a section whose heading contains "work", "experience", "employment", "history" or "job". Education needs the word "education". Skills needs "skill".

That explains every row of the table. "MY JOURNEY" in bold capitals passed the first test, so the parser knew a section started there, but no work keyword matched, so the two jobs went unfiled. "Employment History" in title case failed the first test (neither word is in the heading list), even though the second step would have accepted it. "ACADEMIC BACKGROUND" in bold capitals passed the first test, but only the word "education" leads to the education field, so the degree was dropped.

Commercial parsers are larger systems than a keyword list: Textkernel's specifications say its parser works in 29 languages with automatic language detection. We could not run Workday, Greenhouse or Textkernel ourselves, so we do not claim they lose "Academic Background". The vendor documentation quoted above points the same way, though: Textkernel asks for "commonly-used" headers and RChilli lists unusual and combined headings as problems. A standard label works in the simple parser and the sophisticated one; a creative label is a bet on the sophisticated one.

What goes in the resume header (the top block)

The top block has no heading at all. Put your name on the first line, then one contact line: phone, email, city and state, and a LinkedIn URL if you have one. The first rule below comes from the vendors; the other two come from our own test runs.

Keep it in the page body. Greenhouse lists "Resumes with the name and contact information in the header, footer, or text box" as a parse failure cause. RChilli's tips carry the heading "Do Not Use Header/Footer" and call contact details in the header "not a good idea", although the same item says its parser treats a Word header as a place for personal information, so behaviour differs by parser. The Word page header looks like the obvious home for a letterhead-style name, and it is the one placement that some systems skip entirely.

Skip the title line. In a separate run we placed a bold "RESUME" line above the name, and the parser filled the name field with "RESUME" instead of "Jordan Avery". Your file name and the layout of the page already tell the reader what the document is.

Give the name some room. The parser looks for your name in the lines above the first heading, and pdf.js decides where each line ends. With the name in 20 pt and 0 to 4 pt of space below it, pdf.js returned the name and the contact line as a single line, and the parser read the name as "Summary" and the email as "Averyjordan.avery@example.com". At 16 pt, or at 20 pt with 8 pt of space below, the two lines came out separately and everything parsed. That threshold belongs to one extraction library, but the fix costs nothing: a name in 14 to 18 pt with clear space before the contact line.

How to format headings so a parser finds them

The label is half the job. The other half is making the heading look like a heading to software that cannot see your design.

1. Put each heading on its own line, with nothing else on it. Textkernel's code 151 flags sections "with the header not on a separate line above the content", and OpenResume does not treat a line holding more than one text item as a heading.
2. Make headings bold, and consider capitals. Bold capitals were the only style in which OpenResume recognised every synonym label as a heading (filing its contents is the separate step described above). Title case is fine for the standard labels, which passed in all three styles.
3. Leave a break after the heading. For Word files, RChilli says that if a heading "does not have sufficient space after it e.g. Tab, Colon, New line", the parser "will not pick up the whole block". A new line is the safe choice.
4. One topic per heading. RChilli's problem list includes combined headings, with "Education/Skill/training" as its example. Split them into separate sections.
5. No sub-headings inside a section. RChilli's example shows an "Achievements:" label inside the Education block as the wrong way; fold achievements into the entry as bullets.
6. No letter spacing on headings. Wide tracking turns "EXPERIENCE" into "E X P E R I E N C E" in extraction, which Greenhouse also lists as a failure cause. Our ATS-friendly resume format guide covers that and the other layout breakers.

Then test the exact file you will send. Open the PDF, select all, paste it into a plain text editor and read the headings: each should sit alone on a line, spelled normally, above its own content. You can also run your resume through our free ATS checker, which extracts the text from your file and flags it when it cannot find standard Experience, Education or Skills headings. Neither test reproduces a particular employer's ATS, so treat a clean result as the minimum, not a guarantee.

What are the 5 sections of a resume?+

Contact details at the top, a summary, work experience, education and skills. Certifications, projects and languages are common additions. Use those exact words as headings; in our parser test, standard labels kept every field while creative ones lost them.

Is 'Professional Experience' as good as 'Work Experience'?+

For the jobs themselves, yes: both jobs parsed under it in every style of our test. The trouble came from the labels around it. When 'Academic Background' and 'Core Competencies' were not recognised as headings, their lines were filed as extra jobs under Professional Experience. 'Work Experience' or 'Experience' with standard neighbours parsed in all three styles.

Can I use creative headings for a design or marketing job?+

Put the creativity in the content. 'My Journey' and 'Toolbox' lost the work history and skills in all six of our test files. A recruiter reading the PDF still sees your design; the parser only sees the words.

Should resume headings be all caps?+

Either works for standard labels. In the open-source parser we tested, bold capitals are the main signal for a heading, and they rescued some synonym labels that title case lost. Avoid letter spacing on capitals.

Should I write 'Resume' at the top?+

No. In our test a 'RESUME' line above the name was read as the candidate's name. Start with your name.

Key takeaways

• A heading tells a parser where a section starts and which field it feeds; a block under an unrecognised heading can end up unfiled or attached to the wrong job.
• In our 21-file test, Summary, Work Experience, Education and Skills kept every field in every style, while creative labels kept none.
• "Safe-sounding" synonyms are the hidden risk: Academic Background, Qualifications, Core Competencies and Expertise lost the degree or skills even in bold capitals.
• We could not test Workday or Greenhouse directly, but the parsing vendors' own documentation asks for the same thing: common, clearly separated headings.
• The top block needs no heading: name first in the page body, contact line below it, no "Resume" title and nothing in the Word page header.