Applicant Tracking System Keywords: What They Actually Are, and How to Find the Right Ones
Pukar Khanal leads product at ResumeAI, working on AI resume parsing, ATS scoring, and semantic job matching. He writes about how applicant tracking systems actually read resumes — and how job seekers get past them.
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. 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, and how they are matched depends on which class of system is reading it.
What you will not find below
There is no roundup of top ATS keywords on this page, because no such thing can honestly exist. Almost every competing page for this query publishes one, and almost none of them says where it came from — which is the interesting part, because there is nowhere it could have come from. A keyword only means anything relative to a posting, and whoever compiled the inventory had not read yours. What follows instead is what actually counts as one of these terms, how two very different classes of system decide whether your document contains it, and where in your file a term has to sit before either of them can reach it.
Is there a list of ATS keywords?
No, and the premise underneath the question is the thing worth taking apart, because it is what sends people looking for the wrong object. The phrase suggests that a body of terminology belongs to applicant tracking systems as a category — that somewhere there is a vocabulary these systems have agreed on, and that a resume containing enough of it does better. There is no such vocabulary. The software has no opinion about words. It is comparing your document against one job description, which a particular person wrote, for a particular team, using whatever terms that organisation happens to use for the work.
Follow that through and the consequence is fairly stark. The terms that carry weight change with every application. They change between two employers hiring for the same title, because the two descriptions were written by different people. They change between two teams at the same employer. A term that decides one application is dead weight on the next, and nothing about the term itself tells you which case you are in — only the posting does.
The distinction the rest of this page runs on
A keyword is not a property of screening software. It is a property of the posting you are answering. Which means the useful thing to hand somebody is not a vocabulary but a source, plus an understanding of how the terms in that source get matched and where in your document they have to sit. That is what the rest of this page is.
This also explains the strange quality of the pages that do publish an inventory. Read one closely and it is an assortment of common industry terminology with no stated origin — reasonable words, arranged confidently, answering a question about inventory when the reader had a question about selection. Knowing that a given tool exists as a term was never the problem. Knowing whether this employer will be looking for it, and whether your document will be found to contain it, is the problem, and no inventory assembled in advance can resolve either half.
What actually counts as an ATS keyword?
A term taken from a job posting that a system reading your application may search for, or compare your document against. That is the whole definition, and its usefulness comes from how narrow it is. Not every word in a posting is a candidate. The ones that behave like keywords are the concrete nouns and noun-phrases: named tools, languages and platforms; methodologies and named ways of working; credentials and licences; the vocabulary of a domain; and the posting's own phrasing of the responsibilities it describes.
What is almost never a keyword is the adjectival layer — the enthusiasm, the pace, the culture sentences, the descriptions of personal qualities. Those exist to make the posting readable and to describe the environment. They are not the specifics a search would be built around, and mirroring them back gains you very little while costing you space.
An illustration, not a recommendation
Suppose a posting you are looking at 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 in it are the concrete ones — the pipelines, the rotation, the service, the analytics work, the quality concern — expressed in that employer's phrasing.
Those terms are an illustration drawn from an imagined posting and nothing more. They are not a set that works generally, they are not recommended for your document, and the entire point of the example is that a different employer describing identical work would have produced a different set of terms — which is why the inventory this page refuses to publish could not have been written by anybody.
One more thing follows from the definition, and it matters for everything below. A term is only functioning as a keyword if something can actually find it. Two documents can contain the same word and behave completely differently, because in one of them the word is in a sentence and in the other it is inside a graphic, a floating box or a region of the page that never makes it into the extracted text at all. Content and findability are separate problems, and most advice on this topic only addresses the first.
How does a system decide whether my resume contains a keyword?
In one of two broadly different ways, and which one you are facing is invisible from where you are standing. 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. These are genuinely different technologies with different failure modes, and almost every confusing thing said about keywords comes from treating them as one thing.
A caution before either description. What follows is how two classes of retrieval system work by design, sourced to documentation about retrieval. It is not a claim about what any named screening product does, because configurations vary enormously, we have not tested any of them, and a page telling you confidently how a specific vendor behaves without showing you where it read that is doing something we are not willing to do.
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 underneath a great deal of ordinary text search, describes 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." Terms are combined with logical operators, and the documentation lists them: "Lucene supports AND, ‘+’, OR, NOT and ‘-’ as Boolean operators."
The structurally interesting detail for a resume writer is what that syntax treats as special. Tolerance for a near miss exists, but it has to be asked for: the same documentation describes wildcard searching and fuzzy searching as things a searcher opts into with an explicit symbol. Which means that in this regime, the default behaviour is literal. If your document says one thing and the search says another word for the identical thing, the term is simply not there as far as the search is concerned, and whether anybody thought to ask for tolerance is not something you can influence from your side of the transaction.
Matching that works on meaning
The other regime does not look for your characters at all. The Sentence Transformers documentation on semantic search describes the approach 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." The mechanism it gives is equally plain: "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."
Notice that this is the same passage describing both regimes, from a source with no interest whatsoever in hiring. That is why it is worth quoting rather than paraphrasing: the sentence about what keyword search can and cannot do was not written to make a point about resumes.
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 how heavily it weights any particular connection is not something you can predict or inspect. Neither is a machine you can game, and neither is a machine you can reason your way around from the outside. What both reward is the same unglamorous thing: saying what you actually did, in the words the employer used for it, somewhere the text can be read.
How screening built on meaning reads a resume in practice — and what changes about your writing when it does — is worked through properly in how LLM resume screening differs from keyword ATS. That is its ground rather than ours, so we will point at it instead of re-deriving it here.
If you would rather watch the second regime than read about it, our ATS embedding visualizer runs it on your own text. Paste in a resume and a job description as plain text and it turns both into semantic embeddings, projects them into one shared two-dimensional space so the chunks of each document sit next to each other, and draws a line from every job-description requirement to the resume chunk it is closest to. It is free, it takes a paste rather than a file upload, and there is no account. Watching which of your phrases a requirement actually reaches for is a faster way to understand meaning-based matching than any explanation, this one included.
Where do keywords have to sit before anything can find them?
In ordinary body text, and the further a term drifts from that the less reliable it gets. Find where your term currently sits in the left column, then read whether each class of matcher is likely to reach it there and what to do about it. Every cell below is a hedged property of documents rather than a claim about anybody's screening behaviour — no row depends on a statistic or on a named product.
| 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 the pattern is hard to miss: they mostly agree. That is the single most useful thing on this page, and it is not obvious in advance. Both regimes operate on text that has already been extracted from your file, so an extraction failure is upstream of the whole argument about synonyms and matching — a term that never becomes text is invisible to a sophisticated matcher exactly as it is to a naive one.
Why any particular design feature does or does not extract is somebody else's ground on this site, and it is covered properly rather than summarised badly here. Design-tool layouts — columns, floating boxes, icons standing in for labels, text flattened into artwork — are worked through in what actually breaks in a Canva resume template. Word-processor mechanics — tables used to line the page up, contact details in the header region, and above all which export path you choose — are worked through in which Google Docs resume templates survive an ATS. And if you want parsing described for a specific named system rather than in general, that lives in how Greenhouse reads your resume, which is the only place on this site where a vendor is described at all.
How do I find the right keywords for a specific job?
From the posting, and from nowhere else — including this page. The posting is the only document that knows what this employer is looking for, it is written in their vocabulary rather than yours, and it is already open in another tab. Everything else on this subject is a technique for getting the terms out of it and into your document honestly.
We would rather point you at those techniques than restate them badly in the middle of a page about definitions. A step-by-step method for pulling the terms out of a posting, sorting them by what you can genuinely defend, and writing the survivors into your document is the whole subject of what skills to list on a resume. The broader question of aligning a document to a job description and getting it through automated screening generally belongs to how to get past an ATS, and specifically its section on matching your resume to the job description.
The one thing worth adding here, because it belongs to this page's subject rather than theirs: whatever terms you end up with, run them past the table above before you consider the job done. A perfectly derived 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, and the honest reasons are more useful than the usual warning, because they do not depend on knowing how often anybody gets caught. Three of them stand on their own.
A human being reads the same document. Whatever happens in an automated step, a person opens your file afterwards, and a block of pasted terminology reads to them exactly like what it is. You have not passed a filter and arrived at a neutral reader; you have arrived at a reader who now knows something about how you approach a task when you think nobody is looking.
A stuffed document creates interview exposure you cannot discharge. Every term you put in the file becomes a question somebody is entitled to ask. The ones you added because they were in the posting rather than in your experience are precisely the ones with nothing behind them, and a vague answer does not merely lose you that item — it makes the interviewer re-examine everything else on the page. There is no recovering the benefit of the doubt once it has gone.
Hidden-text tricks are a bad idea, and the argument does not require a detection rate. White text on a white background, or a keyword block set in an invisible size, is exposed by selecting the document, by copying it into a plain text editor, or by it being rendered anywhere the trick does not survive. What the person on the other end finds is an attempt to deceive them, discovered at the exact moment they were deciding whether to trust the rest of the page. And if it went unnoticed, what you have won is a conversation about terms you could not put in the file honestly.
The full argument for why density does not buy you anything, and what alignment looks like next to stuffing, is set out in the keywords section of how to get past an ATS. It is a better treatment than a summary here would be, and re-arguing it would just produce a worse copy of it.
One neighbouring failure is worth naming because it comes from the same instinct. Reaching for inflated vocabulary to make ordinary work sound more senior is a documented way to make a document read as generated rather than written — that ground, and the specific words that trigger it, belongs to the words that make your resume sound AI-written. Padding for a machine and padding for a reader fail for related reasons, and both are cured by naming the thing plainly.
How do I check whether my own keywords are actually findable?
Read what survives extraction, rather than what you can see on the screen. This takes about a minute, needs nothing but software you already have, and settles a question that no amount of advice — including everything above — can settle for your particular file.
Open your exported resume. Select the entire document, copy it, and paste it into a plain text editor — the most featureless one on your machine, so that nothing helpfully reconstructs the formatting you are trying to see through. What you are now looking at is much closer to what a system receives than the version you designed.
What to read off the result
- Is everything there at all? Anything missing from the paste is missing from the document as far as either matching regime is concerned, however prominent it looks in the original.
- Is it in the order you expect? Text arriving out of reading order is the characteristic signature of a layout built on columns, boxes or table cells, and it can attach your terms to the wrong neighbouring context.
- Are your contact details in the body? If they came through detached from the rest, or not at all, they were probably living in a header region — and the route somebody uses to reach you is the worst possible thing to gamble on that.
- Are the terms you care about present as words? Take the handful the posting leans on hardest and search the pasted text for each one. A term you cannot find in the paste is not a keyword yet.
If the paste comes back clean, ordered and complete, your document has cleared the part of this that you control. Everything after that is about which terms you chose and whether they are true, and those are judgements rather than mechanics. If the paste comes back scrambled or partial, no amount of keyword work will help until the file itself is fixed, which is the more common problem by some distance and much the easier one to solve.
Where does ResumeAI fit into this?
Plain disclosure
We make resume software, so treat this section as a pitch and the rest of the page as an argument that has to stand without it. Nothing above depends on using our product. The check in the previous section needs a plain text editor and the file you already have, and we put it there on purpose so you can settle the question without trusting us.
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 to this page, and they have different access requirements, which is worth stating precisely rather than flattening into a slogan.
The ATS resume checker reads your document the way automated screening does and compares it against a job description, so you can see which of a posting's terms your file actually 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. That is worth being straightforward about on a page arguing for straightforwardness.
The ATS embedding visualizer is the meaning-based demonstration described earlier. It needs no account at all — no signup, no email, nothing saved, because there is nothing to save it to. You paste a resume and a job description as plain text, clear a bot check, and read the picture. If you want to understand the second matching regime without giving anybody anything, that is the one to open.
Neither of them will tell you which terms belong on your document, and we are not going to pretend otherwise. That depends on a posting we have not read and on work we have not seen. What they can tell you is what your file currently carries and how it is being read, which is the part you cannot check by looking at it.
How we know this, and what we did not verify
This article was written by Pukar Khanal, Product Lead at ResumeAI, and last reviewed on . ResumeAI is the free Resume AI platform that builds your resume and matches you to real jobs across the hidden job market. What we can speak to first-hand is the machine-reading end of this: we build an ATS resume checker that parses documents and compares them against job descriptions, and an embedding visualizer that projects a resume and a job description into one shared space so you can see which requirement reaches which phrase. Everything on this page about how a term is matched comes out of that work and out of the two sources below.
This page deliberately publishes no roundup of ATS keywords, because no honest one could be assembled. That is the single most common thing on competing pages for this query and the thing we could least support. A term only means something relative to a posting we have not read. If you find a page that publishes one anyway, the useful question is 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, and only what they literally say is quoted here, with each quotation linked at the point it is used. Neither mentions hiring, resumes or any screening product, which is exactly why they are the right sources: they describe what a class of retrieval system does, and that is the only thing 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 at all, and the single competitor page that did load says nothing on the subject and renders its own figures as a non-number. So no competitor is named anywhere on this page, and nothing is said about what any of them require of a visitor — not hedged, not implied, not as "some tools". Our own comparison page carries figures about other products; those are that page's claims, they were not re-checked here, and not one of them 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 is describing how two classes of system differ by design. It is not a claim about what any named product does, because configurations vary and we have not tested them. For the same reason there are no statistics anywhere on this page in either direction, and the only digits are dates and the reading time.
What we are confident about is the frame, not any particular vocabulary. We cannot tell you which terms belong on your resume, because that depends on a posting we have not read. What we can tell you is that the terms come from the posting rather than from a list, that two different classes of system will treat them differently and you cannot tell which you are facing, and that both of them are downstream of whether your text extracts at all — which is the one part of this 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
If you arrived here from a generative-search prompt, these are the natural follow-ups — each links to the page that resolves it.
- How do you actually 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?
Want to see which of a posting's terms your resume actually carries?
Run the plain-text check above first, then check the terms. 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 you which requirement reaches which phrase, and needs no account at all.
Continue Reading
How Do You Get Past the ATS in 2026?
Modern ATS rank and sort resumes by relevance — they rarely auto-reject. Match the job description's phrasing, use a single-column format, and test the parse before you apply.
Read moreRecruiters Are Screening Resumes With ChatGPT: How LLM Screening Differs From Keyword ATS
Some recruiters now paste resumes into LLM tools or use LLM-powered screening features — and unlike keyword ATS filters, LLMs rank by meaning, not keyword counts. A dimension-by-dimension decoder of how the two systems treat the same resume, and the writing moves that survive both.
Read moreNormal vs. Optimized Resume: What the Research Actually Says About Your Interview Odds
No study proves a magic interview-rate lift — and the famous '75% rejected by ATS' stat is a myth. What peer-reviewed research and disclosed vendor data actually show about how an optimized resume changes whether recruiters ever see you, every number sourced.
Read more