Resume keywords are the terms a job description repeats and asks for explicitly: hard skills and tools (TypeScript, Kubernetes, Salesforce), credentials (PMP, CPA, RN), industry terminology (go-to-market, A/B testing, ICD-10), and the verbs the JD uses to describe the work (led, built, migrated, launched). Find them by reading the JD twice — once for context, once to extract every term in those four buckets — and mirror the most-repeated ones verbatim in your resume. Tools extract them automatically, but a manual pass teaches you what the role actually values, which helps you write a stronger summary later.
The 4 types of keywords
Hard skills and tools are the heaviest-weighted. These are specific, teachable, and verifiable: programming languages and frameworks (TypeScript, React, Spring), platforms and software (Salesforce, Workday, Tableau, Figma), and methodologies (Scrum, Kanban, ITIL). They appear most often in the requirements and nice-to-have sections, and they're the terms an ATS scores most literally — if the JD says "TypeScript" and your resume says "strong JS experience," you may miss the match.
Soft skills are weighted lighter but still matter: "stakeholder management," "cross-functional leadership," "written communication," "mentoring." Mirror them where you can back them up with a bullet — a claim of "stakeholder management" lands better when paired with "aligned roadmap across 4 product teams." Recruiters scan for these cues as they read.
Credentials and certifications are easy to mirror exactly because they're standardized: PMP, CPA, CFA, RN, AWS Certified Solutions Architect, Scrum Master (CSM). If the JD lists one and you have it, put it in a Certifications section by its full, official name — no abbreviation the JD doesn't use. If the JD says "PMP preferred" and you're PMP-certified, that's a near-automatic keyword match.
Industry terminology and verbs round out the set. "Go-to-market," "pipeline," "ICD-10," "SOX compliance," "user acquisition," "net retention" — these are the words that signal you've worked in this domain before. The verbs matter too: if the JD says "led" and "scaled," your bullets should lead with "led" and "scaled," not "helped with" and "worked on." Verbs signal seniority and ownership; match the JD's level. A common mistake is to match the nouns (skills, tools) but leave weak verbs in place — "helped launch" where the JD says "led launch" understates your contribution and undercuts your keyword score at the same time.
Frequency matters too. A keyword that appears three times in the JD — once in the summary, once in responsibilities, once in requirements — is weighted more heavily than one that appears once. When you sort your extraction list, count how many times each term repeats in the posting and prioritize the repeats. The repeats are the role's actual center of gravity; the singletons are often nice-to-haves the hiring manager tacked on. Mirroring the repeats verbatim moves your score more per minute of editing than chasing every singleton.
A worked example
Here's a fictional job description snippet for a senior backend role, with the keywords that should end up in your resume bolded inline:
"We're hiring a **Senior Backend Engineer** to **scale** our payments platform. You'll **design and ship** high-throughput **Go services** on **Kubernetes**, own **Postgres** schema and query performance, and partner with the **SRE team** on **observability** (Prometheus, Grafana). **Distributed systems** experience and a track record of **reducing latency** are required. Familiarity with **Kafka** or event-driven architecture is a plus."
Extracting the keywords above gives you a checklist of what your resume needs to show, in the JD's exact words:
- Senior Backend Engineer — match the title where your titles allow it
- scale, design and ship, reducing latency — match the verbs and outcomes in your bullets
- Go, Kubernetes, Postgres, Kafka — hard skills; list each by the exact name the JD uses
- SRE team, observability, Prometheus, Grafana — adjacent skills worth surfacing if you have them
- distributed systems, payments platform, event-driven architecture — domain terminology to mirror if it's true of your work
Notice the extraction is honest: you only mirror a keyword if you actually have the skill. The point is to surface what's true about you in the JD's vocabulary, not to invent skills you don't have. Recruiters and hiring managers will probe anything you list — a keyword you can't defend in an interview is worse than a missing one.
A second worked example: a marketing role
The extraction pattern isn't specific to engineering — it works the same way for non-technical roles, where the keywords tilt toward platforms, channels, metrics, and methodologies rather than languages and frameworks. Here's a fictional snippet for a senior growth-marketing role, with the keywords bolded inline:
"We're looking for a **Senior Growth Marketing Manager** to **own pipeline** and **customer acquisition** across **paid search** and **paid social**. You'll **run multi-channel campaigns** on **Google Ads** and **Meta Ads**, **optimize CAC** and **LTV**, and partner with **content** and **lifecycle** teams on **nurturing flows**. Experience with **HubSpot**, **Segment**, and **A/B testing** is required. You should be comfortable building **dashboards** and **reporting to leadership**."
Extracting the keywords gives you a non-technical checklist that mirrors the JD's exact vocabulary:
- Senior Growth Marketing Manager — match the title where your titles allow it
- own pipeline, customer acquisition, optimize CAC, optimize LTV — outcomes and metrics to mirror in your bullets, with numbers
- paid search, paid social, multi-channel campaigns — channel expertise to list verbatim in Skills
- Google Ads, Meta Ads, HubSpot, Segment — platforms; list each by the exact product name the JD uses
- content, lifecycle, nurturing flows — adjacent functions you've partnered with; mention if true
- A/B testing, dashboards, reporting to leadership — methodologies and verbs; mirror in bullets with the scope of what you tested or reported
Notice the structural similarity to the engineering example even though the vocabulary is entirely different. Both checklists separate title-match, outcome-match, hard-skill-match, and verb-match, and both weight repetition: "paid search" and "paid social" each appear twice in the JD, which is the signal to mirror them exactly rather than collapse them into a vague "paid media" line. The same extraction discipline — read twice, categorize into the four buckets, count repeats, mirror verbatim — applies to any role, technical or not. For role-specific starting points, the marketing and other role guides list the common ATS keywords per job family.
Synonyms, variants, and acronyms
A subtler extraction problem: the JD and your resume often describe the same skill with different words, and you have to decide which form to use. "Customer acquisition" versus "user acquisition"; "paid social" versus "social ads" versus "Facebook ads"; "Go" versus "Golang"; "React" versus "React.js" versus "ReactJS"; "CI/CD" versus "continuous integration". Each of these is the same skill, but an ATS scoring on literal strings treats them as different keywords. Get the form wrong and you lose the match even though you have the skill.
The default rule is simple: use the exact form the JD uses. If the JD says "paid social", your resume says "paid social" — not "social ads". If the JD says "Go", your resume says "Go" — not "Golang". If the JD spells out "continuous integration", you spell it out; if it abbreviates "CI/CD", you abbreviate. Mirroring the JD's form is the single highest-leverage choice you can make on synonyms, and it costs you nothing — the meaning is identical, only the string differs.
What if the JD uses a form you can't be sure every ATS will recognize? Then hedge by including both forms, but in a way that reads naturally to a human. "Go (Golang)" in your Skills section covers both strings without looking awkward. "Paid social (Facebook Ads, Instagram Ads)" covers the category and the specific platforms. "Continuous integration / CI/CD" works the same way. The goal is to be found by both the strict matcher and the human reader, and the parenthetical-or-slash form does both without keyword-stuffing. Avoid the trap of listing every synonym as a separate line — "Go, Golang, Go-lang, Google Go" reads as padding to a human and signals the same to sophisticated ATS, so it hurts more than it helps.
Acronyms deserve a special note because they cut both ways. Spell out an acronym the first time you use it in a bullet ("search engine optimization (SEO)") so a human reader and a semantic matcher both pick it up, then use the short form thereafter. In the Skills section, list the form the JD uses first and the alternate form in parentheses if you're unsure. The pattern protects you against the strict-literal matcher (which only sees the exact string) and the semantic matcher (which understands both) at the same time, without inflating the resume. See the tailoring guide for where these keyword choices fit into the larger per-application workflow.
Where to put them
Skills section first. A dedicated Skills section — usually right under your summary, or at the bottom of the page — is where an ATS and a recruiter both look for hard-skill keywords. Group by category (Languages, Frameworks, Tools, Platforms) and list each term verbatim. This is the highest-density keyword zone on the resume, and it's where the matcher will look first.
Inside bullets next. Skills listed in isolation read as a wall; skills proven in context read as evidence. For each major hard skill, at least one bullet under the relevant role should use the term and attach a result — "Reduced p99 latency 40% on Go services handling 8K rps." The matcher weights keywords in bullets as well as in the Skills section, so put them in both.
Summary last, and sparingly. Your summary can carry one or two of the JD's headline terms ("Backend engineer with 7 years scaling Go services in payments"), but don't cram every keyword in — it reads as stuffed and it pushes the summary past the point where a recruiter finishes it. Reserve the summary for the two or three terms that define the role's senior pitch. The warning that applies everywhere: don't keyword-stuff. If you can't back a term with a bullet, leave it out. See the tailoring guide for the full method.
One nuance on the Skills section: don't duplicate a skill across every category just to repeat the keyword. Listing "PostgreSQL" under both Databases and Backend doesn't double your score — most matchers deduplicate — and it signals to a human reader that you're padding. List each skill once, in the category where it most naturally belongs. The same goes for acronyms: pick the form the JD uses ("PostgreSQL" if the JD says PostgreSQL, "Postgres" if it says Postgres) and use it consistently throughout the resume. Mixed usage reads as careless and can split the keyword match in some parsers.
Shortcut
The manual extraction above takes 15–30 minutes per application, which is fine for your top three roles and painful for application number twenty. The JDMatcher matcher extracts the keywords from a pasted JD automatically and returns them as a checklist, then rewrites your bullets to mirror the ones you actually have — usually in about 15 seconds. For a head start on what each role's JDs typically ask for, the resume guides by role list the common ATS keywords per job family — pick your target role and you'll see the terms parsers most often look for before you even open a specific posting.