What is the difference between Cucumber and Gherkin?

Cucumber and Gherkin are not two competing testing tools. They are two layers of one system: Gherkin is the plain-language Given/When/Then syntax for writing test scenarios, and Cucumber, created by Aslak Hellesøy in 2008, is the software that parses .feature files written in that syntax and runs them against step-definition code in Ruby, Java, or JavaScript.

Where does the confusion come from?

The two names get used interchangeably because most people only see them together. In a Cucumber project, every .feature file is written in Gherkin, so the syntax and the runner blur into a single experience. But Gherkin is a specification, not an executable. On its own it cannot run a test. It needs a parser and a runner behind it, and Cucumber was the first tool built for that job.

Which tools actually read Gherkin?

Cucumber is not the only consumer of Gherkin syntax. SpecFlow, the long-standing .NET implementation now succeeded by Reqnroll, parses the same Given/When/Then structure. So do Behave for Python and JBehave for Java. A team can write identical .feature files and run them through any of these tools, which shows that Gherkin the language and Cucumber the tool are separate things.

Why does the distinction matter for hiring?

A resume or job posting that says "Gherkin experience" usually means the person can write readable acceptance criteria, a skill that transfers across frameworks. "Cucumber experience" is narrower. It points to hands-on work with step definitions, hooks, and that specific runner's configuration in a given language. Screening for the right one prevents hiring someone who can write scenarios but has never touched the automation layer, or the reverse.