Resume Building
Applicant Tracking System Keywords: What They Are and How to Find Them
By Pukar Khanal, Product Lead at ResumeAI
13 min readPublished
Pukar Khanal leads product at ResumeAI, working on AI resume parsing, ATS scoring, and semantic job matching. He writes about how applicant tracking systems read resumes and how job seekers get past them.
There is no universal list of applicant tracking system keywords. The keywords that matter are the vocabulary of the specific posting in front of you. How they get matched depends on which class of system is reading your file, and where in the file they sit.
ResumeAI, the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market, reviewed this question on 22 July 2026. People search for it as "applicant tracking system keywords" and "applicant tracking software keywords." Both mean the same thing, and neither has a master list.
Key takeaways
- Keywords belong to the posting. A keyword is not a property of screening software. It is a property of the posting you are answering.
- Two matching regimes. A character-based search can miss a true synonym. A meaning-based matcher connects related concepts, but you can't predict how it weights them.
- Placement decides findability. A term that never becomes extracted text is invisible to both regimes. Keep terms in ordinary body text.
- Check your own file. Copy the whole document into a plain text editor. A term you can't find in the paste is not a keyword yet.
Is there a list of ATS keywords?
No. The question assumes a vocabulary that applicant tracking systems share, so that a resume containing enough of it does better. That vocabulary doesn't exist. The software has no opinion about words. It compares your document against one job description, written by one person, for one team, in whatever terms that organisation uses for the work.
So the terms that carry weight change with every application. They change between two employers hiring for the same title, because different people wrote the two descriptions. They change between two teams at the same employer. A term that decides one application is dead weight on the next. Only the posting tells you which case you are in.
Pages that publish an inventory anyway tend to offer common industry terms with no stated origin. Knowing that a tool exists as a term was never the problem. The problem is whether this employer is looking for it, and whether your document will be found to contain it. No list assembled in advance can answer either.
What counts as an ATS keyword?
A term from a job posting that a system reading your application may search for, or compare your document against. Not every word in a posting qualifies. The ones that behave like keywords are the concrete nouns and noun phrases: named tools, languages and platforms, methodologies, credentials and licences, domain vocabulary, and the posting's own phrasing of the responsibilities.
The adjectival layer is almost never a keyword. Enthusiasm, pace, culture sentences and personal qualities make the posting readable. A search isn't built around them, and mirroring them back costs you space for very little.
Example
Suppose a posting contains this sentence. Maintain our ingestion pipelines, own the on-call rotation for the reporting service, and work with the analytics team on data quality. The terms behaving like keywords are the concrete ones: the pipelines, the rotation, the service, the analytics work and the quality concern, in that employer's phrasing.
These terms come from an imagined posting. They are not a set that works generally, and they are not recommended for your document. A different employer describing identical work would have used different terms.
A term only works as a keyword if something can find it. Two documents can contain the same word and behave differently. In one, the word sits in a sentence. In the other, it sits in a graphic, a floating box, or a region of the page that never reaches the extracted text. Content and findability are separate problems, and most advice only covers the first.
How does a system decide whether my resume contains a keyword?
In one of two broadly different ways, and you can't see which one you are facing. The first compares characters. It looks for the term it was given in the text it was handed. The second compares meaning. It turns both documents into numerical representations and asks how close they are. Most confusing advice about keywords comes from treating these as one thing.
One caution first. What follows is how two classes of retrieval system work by design, sourced to documentation about retrieval. It is not a claim about any named screening product. Configurations vary enormously, and we have not tested any of them.
Search that works on characters
In the classical case, a search is built from terms and operators. The query parser documentation for Apache Lucene, the open-source search library under a great deal of ordinary text search, puts it plainly (read on 22 July 2026): "A query is broken up into terms and operators. There are two types of terms: Single Terms and Phrases." Logical operators combine the terms, and the documentation lists them: "Lucene supports AND, ‘+’, OR, NOT and ‘-’ as Boolean operators."
In this regime, the default is literal. Tolerance for a near miss exists, but the searcher has to ask for it. The same documentation describes wildcard and fuzzy searching as things you opt into with an explicit symbol. If your document uses one word and the search uses another word for the same thing, the term is not there as far as the search is concerned. You can't control whether anybody asked for tolerance.
Matching that works on meaning
The other regime doesn't look for your characters at all. The Sentence Transformers documentation on semantic search describes it directly (read on 22 July 2026): "Semantic search seeks to improve search accuracy by understanding the semantic meaning of the search query and the corpus to search over. Semantic search can also perform well given synonyms, abbreviations, and misspellings, unlike keyword search engines that can only find documents based on lexical matches."
It gives the mechanism just as plainly: "The idea behind semantic search is to embed all entries in your corpus, whether they be sentences, paragraphs, or documents, into a vector space. At search time, the query is embedded into the same vector space and the closest embeddings from your corpus are found." That one passage describes both regimes, and it comes from a source with no interest in hiring. Nobody wrote it to make a point about resumes.
Note
Both regimes fail, and they fail differently. A character-based search can miss a true synonym entirely. A meaning-based matcher will connect related concepts, but you can't predict or inspect how heavily it weights any one connection. You can't game either from the outside. Both reward the same plain thing: saying what you did, in the employer's words, somewhere the text can be read.
How meaning-based screening reads a resume in practice, and what it changes about your writing, is covered in how LLM resume screening differs from keyword ATS.
To watch the second regime work on your own text, open our ATS embedding visualizer. Paste in a resume and a job description as plain text. It turns both into semantic embeddings, projects them into one shared two-dimensional space, and draws a line from every requirement to the resume chunk closest to it. It is free, takes a paste instead of a file upload, and needs no account.
Where do keywords have to sit before anything can find them?
In ordinary body text. The further a term drifts from that, the less reliable it gets. Find where your term sits in the left column, then read whether each class of matcher is likely to reach it and what to do. Every cell is a hedged property of documents, with no statistic or named product behind it.
| Where the keyword sits in your document | Will a character-based search find it? | Will a meaning-based matcher find it? | What to do |
|---|---|---|---|
| Inside an accomplishment bullet | Usually yes. This is ordinary body text, which is the case every extraction path is built for. | Usually yes, and this is where it does its best work, because the surrounding sentence gives the term a context to be compared against rather than a bare token. | Put every term you actually need read here first. A term in a bullet answers two questions at once: whether you have the thing, and what you did with it. |
| In a plainly labelled skills section | Usually yes, provided the section is real text under a heading rather than a graphic or a layout trick. | Usually yes, though a bare list gives it little to work with, so a term here tends to carry less weight than the same term inside a sentence. | Keep it as plain grouped text under a heading a reader would recognise. Treat it as an index into your experience rather than as a substitute for it. |
| In a section heading | Usually yes as text, but headings are often used to work out where sections begin, so a term used as a label may be read as structure rather than as content. | Sometimes. A heading is short and context-free, which is the condition under which matching on meaning is least confident. | Use headings a reader and a parser both expect, and do not rely on a heading to carry a term you need matched. Put the term in the text underneath as well. |
| In the page header or footer region | Varies, and the variation is not visible to you. The documented purpose of that region is repeating on every page, so its contents can be treated as furniture rather than as content. | Varies for the same reason. If the text never reaches the matcher, nothing downstream of extraction can rescue it. | Never put anything you need read here, contact details included. The export-path mechanics are worked through in our Google Docs template post rather than repeated here. |
| Inside a text box or a floating shape | Varies widely. The text may extract, may extract out of reading order, or may not extract at all, depending on how the file was built and exported. | Varies identically. Matching on meaning still needs the characters, so an extraction failure removes the term from consideration whatever the matcher is capable of. | Move the content into the ordinary flow of the page. If a design template put it in a box, that is a property of the template rather than a decision you made. |
| Inside an image, an icon or a graphic | Generally no. A term rendered as artwork is pixels, and there is no text to search. | Generally no, for the same reason. Both regimes operate on extracted text, so a term that never becomes text is invisible to both. | Assume anything shown only as a picture is not read at all. Skill rating bars and icon-labelled contact rows are the common cases, and both should be plain text. |
| In a table cell used for layout | Sometimes, and the order is the risk rather than the presence. Cells may be handed back in storage order rather than in the order your eye follows them. | Sometimes, with the same caveat, and scrambled order can attach a term to the wrong neighbouring context. | Prefer a single-column flow. Where a template leans on tables to line the page up, the design-tool and word-processor mechanics are covered in our template posts. |
| In file metadata or in the filename | Generally not as resume content. Those fields are usually handled separately from the document body, if they are read at all. | Generally not, since the matcher is normally given the extracted document text rather than the file's properties. | Treat metadata as unread. Give the file a plain, human name because a person will see it in a list, and put every real term in the body of the document. |
Read the two middle columns across and they mostly agree. That is the most useful thing on this page, and it isn't obvious in advance. Both regimes work on text already extracted from your file. An extraction failure comes before any question of synonyms. A term that never becomes text is as invisible to a sophisticated matcher as to a naive one.
Why a given design feature does or doesn't extract is covered elsewhere on this site. Design-tool layouts (columns, floating boxes, icons standing in for labels, text flattened into artwork) are in what actually breaks in a Canva resume template. Word-processor mechanics (layout tables, contact details in the header, and which export path you choose) are in which Google Docs resume templates survive an ATS. Parsing for one named system lives in how Greenhouse reads your resume, the only place on this site that describes a vendor.
How do I find the right keywords for a specific job?
From the posting, and from nowhere else, this page included. The posting is the only document that knows what this employer wants. It is written in their vocabulary, and it is already open in another tab.
For a step-by-step method to pull terms out of a posting, sort them by what you can defend, and write them into your document, read what skills to list on a resume. Aligning a document to a job description and getting it through automated screening is covered in how to get past an ATS, especially its section on matching your resume to the job description.
Whatever terms you end up with, run them past the table above. A perfectly chosen set of terms sitting in a text box is not a set of keywords. It is a set of words.
Does keyword stuffing work?
No. Three reasons hold up without knowing how often anybody gets caught.
A human being reads the same document. Whatever the automated step does, a person opens your file afterwards. To them, a block of pasted terminology looks exactly like what it is. You haven't reached a neutral reader. You have reached one who now knows how you approach a task when you think nobody is looking.
A stuffed document creates interview exposure you cannot discharge. Every term in the file is a question somebody may ask. The ones you added because they were in the posting, not in your experience, have nothing behind them. A vague answer loses you that item and makes the interviewer re-examine everything else on the page.
Hidden-text tricks are a bad idea, and the argument does not require a detection rate. White text on white, or a keyword block in an invisible size, shows up when someone selects the document, pastes it into a plain text editor, or opens it anywhere the trick doesn't survive. The reader finds an attempt to deceive them, at the moment they were deciding whether to trust the rest of the page. If it goes unnoticed, you win a conversation about terms you couldn't put in the file honestly.
The full case against density, with alignment shown next to stuffing, is in the keywords section of how to get past an ATS.
A related failure comes from the same instinct. Inflated vocabulary that makes ordinary work sound more senior is a documented way to make a document read as generated. The specific words that trigger it are in the words that make your resume sound AI-written. Padding for a machine and padding for a reader both go away when you name the thing plainly.
How do I check whether my own keywords are findable?
Read what survives extraction, not what you see on screen. It takes about a minute with software you already have, and it settles the question for your particular file.
Open your exported resume. Select the entire document, copy it, and paste it into the most featureless plain text editor on your machine, so nothing rebuilds the formatting. What you see now is much closer to what a system receives than the version you designed.
What to read off the result
- Is everything there? Anything missing from the paste is missing for both matching regimes, however prominent it looks in the original.
- Is it in the order you expect? Text out of reading order is the signature of a layout built on columns, boxes or table cells. It can attach your terms to the wrong neighbouring context.
- Are your contact details in the body? If they came through detached, or not at all, they were probably in a header region. How someone reaches you is the last thing to gamble on.
- Are the terms you care about present as words? Take the handful the posting leans on hardest and search the pasted text for each. A term you can't find in the paste is not a keyword yet.
If the paste comes back clean, ordered and complete, you have cleared the part you control. After that, it is about which terms you chose and whether they are true. If the paste comes back scrambled or partial, keyword work won't help until the file is fixed. That is the more common problem by some distance, and the easier one to solve.
Where does ResumeAI fit into this?
Disclosure
We make resume software, so treat this section as a pitch. Nothing above depends on our product. The check in the previous section needs a plain text editor and the file you already have.
ResumeAI is the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market. Two parts of it are relevant here, and they have different access requirements.
The ATS resume checker reads your document the way automated screening does and compares it against a job description. You see which of a posting's terms your file carries and where they landed. It is free, with no credit card and no watermark, and it works from a free account, so there is a signup step.
The ATS embedding visualizer is the meaning-based demonstration described earlier. It needs no account at all: no signup, no email, and nothing saved, because there is nowhere to save it. You paste a resume and a job description as plain text, clear a bot check, and read the picture.
Neither tool will tell you which terms belong on your document. That depends on a posting we haven't read and work we haven't seen. They show what your file carries now and how it is being read, which you can't check by looking at it.
How we know this, and what we did not verify
Pukar Khanal, Product Lead at ResumeAI, wrote this article and last reviewed it on . ResumeAI is the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market. We build an ATS resume checker that parses documents and compares them against job descriptions. We also build an embedding visualizer that projects a resume and a job description into one shared space. What this page says about matching comes from that work and the two sources below.
This page publishes no roundup of ATS keywords. It is the most common thing on competing pages for this query and the thing we could least support, because a term only means something relative to a posting we haven't read. If a page publishes one anyway, ask where the ordering came from and whether the page will show you.
Two external sources loaded in full, and they are the only ones cited. The Sentence Transformers documentation on semantic search and the Apache Lucene query parser documentation both returned readable pages on the review date. We quote only what they say, and link each quotation where it is used. Neither mentions hiring, resumes or screening products. They describe what a class of retrieval system does, which is all this page claims about matching.
We make no claim about any other product's access requirements, because every attempt to verify one failed. Three entry points into one widely used competitor returned an edge block with no readable prose. Two paths into another do not resolve. The one competitor page that loaded says nothing on the subject and renders its own figures as a non-number. So this page names no competitor and says nothing about what any of them require of a visitor. Our own comparison page carries figures about other products. Those are that page's claims, they were not re-checked here, and none is restated above.
No applicant tracking vendor's behaviour is described either. Four attempts at vendor and government documentation about candidate search returned nothing usable: two not-found responses, one empty body, and one search shell with no article text. Where this page contrasts character-based search with matching on meaning, it describes how two classes of system differ by design. For the same reason there are no statistics on this page, and the only digits are dates and the reading time.
We are confident about the frame, not any particular vocabulary. The terms come from the posting. Two classes of system treat them differently, and you can't tell which you face. Both depend on whether your text extracts at all, which you can check yourself in a minute.
Frequently asked questions
What are ATS keywords?
An ATS keyword is a term from a job posting that a system reading your application may search for, or compare your document against. In practice that means the concrete nouns: named tools, languages, platforms, methodologies, credentials, domain terms, and the posting's own phrasing of the responsibilities it describes. The phrase itself is a little misleading, because it suggests these terms belong to applicant tracking systems as a category, and they do not. They belong to one employer's description of one job. The same term can be decisive on one application and irrelevant on the next, which is why an inventory of terms compiled by anybody who has not read your posting cannot help you very much. What generalises is not the vocabulary but the method: take the terms from the posting you are actually applying to, use them only where they are genuinely true of you, and put them somewhere in the document a reader and a parser can both reach.
Is there a list of ATS keywords?
No, and the reason is structural rather than a matter of nobody having got around to compiling one. A keyword only means something relative to a posting. The system reading your file is comparing it against a specific job description that a specific person wrote, so the terms that carry weight change with every application, every employer and every team's internal vocabulary for the same work. A list assembled in advance cannot know any of that. Pages that publish one are usually publishing an assortment of common industry terms with no stated origin, which is not the same object as the thing the reader came looking for, and the resemblance is what makes it misleading rather than merely unhelpful. The useful replacement is a source rather than a list: the posting in front of you is the only document that knows what this employer is looking for, and it is already open in another tab.
Where do I put keywords on my resume?
In ordinary body text - inside your accomplishment bullets first, and in a plainly labelled skills section second. Those two places are where a term is most likely to survive whatever happens between your file and the person reading it, and where a human skimming will actually see it. The places to avoid are the ones where a term lives in something other than flowing text: inside a header or footer region, inside a text box, inside an image or a logo, or in the file's metadata or its name. Those are not banned, and in some setups they extract perfectly well. But their behaviour varies with how the document was built and how it was exported, so anything you genuinely need read should not depend on them. A useful way to think about it: a term is only a keyword if something can find it, and findability is a property of where it sits at least as much as of what it says.
How many keywords should I use on my resume?
Enough to cover what the posting actually asks for and that you can genuinely defend, and no more, which is a judgement rather than a count. Any page that gives you a precise number is inventing it, because the right answer depends on the posting, the field and how much of your real experience the job touches. Two failure modes bracket the sensible range well enough to steer by. Too few, and a requirement the employer stated explicitly has no corresponding term anywhere in your document, so a search for it simply fails and a reader has to work out for themselves whether you have it. Too many, and the document reads as a term dump, the important items get harder to spot among the padding, and you have created interview exposure on everything you listed but cannot discuss. The test that replaces the count is whether you could talk about each item for several minutes under questioning from somebody who does it for a living.
Does an ATS understand synonyms?
Some kinds of system do and some kinds do not, and you usually cannot tell from the outside which one is reading you. Two very different things get called screening. Search that works on characters finds the term it was given; a different word for the identical thing is, as far as it is concerned, simply absent, and tolerance for a near-miss is generally something the person searching has to ask for explicitly rather than something they get by default. Matching built on meaning behaves differently: the documentation for one widely used implementation of it says plainly that this approach can perform well given synonyms, abbreviations and misspellings, unlike keyword search engines that can only find documents based on lexical matches. So the honest answer is that it depends on the class of system, that the class is invisible to you, and that this is exactly why using the employer's own word for something you have genuinely done costs you nothing and removes a risk.
Is copying the job description into my resume keyword stuffing?
Pasting the posting in is stuffing; choosing the employer's word for something you genuinely did is not, and the line between them is clearer than it sounds. If a posting names a tool one way and your document names the same tool another way, adopting their label is not adding a claim - it is removing a translation step that whatever reads your file would otherwise have to perform, and might not. That is a free reduction in risk on something already true of you. Pasting whole requirement sentences into a skills block is a different act. It adds claims you did not make, it reads to a human exactly like what it is, and it produces a document that cannot survive the interview it is trying to win, because the first specific question about any pasted line has no answer behind it. The boundary is honesty, and it is not fuzzy: mirror wording only for work that is genuinely yours.
Does white text keyword stuffing work?
It is a bad idea, and the argument against it does not require knowing how often it is caught. Start with the obvious: a human being opens your document after any automated step, and hidden text is trivially exposed by selecting all of it, by copying it into a plain text editor, or by the document simply being rendered somewhere the trick does not survive. What that person finds is not a clever candidate but an attempt to deceive them, discovered at the exact moment they were deciding whether to trust the rest of the page. Then consider what you would have won if it went unnoticed: a conversation about terms you put in the file specifically because you could not put them in it honestly. Every one of them is a question you cannot answer. The technique is aimed at a mental model of automated screening as a naive word counter, and it costs you the thing you were actually competing for either way.
What to ask next
Common follow-ups, each linked to the page that answers it.
- How do you get a resume past an applicant tracking system?
- Which skills should you list on a resume, and how do you choose them?
- How does screening built on meaning differ from keyword filtering?
- What makes a resume format ATS-friendly in the first place?
- How does one specific applicant tracking system read a resume?
See which of a posting's terms your resume carries
Run the plain-text check above first. Then our ATS checker reads your document the way screening software does and compares it against a job description. It is free and works from a free account. The embedding visualizer shows which requirement reaches which phrase, and needs no account at all.
Related guides
Keep reading
- Resume Building12 minHow Do You Get Past the ATS in 2026?Read the guide
- Resume Building13 minRecruiters Are Screening Resumes With ChatGPT: How LLM Screening Differs From Keyword ATSRead the guide
- Resume Building13 minNormal vs. Optimized Resume: What the Research Actually Says About Your Interview OddsRead the guide