Gherkin Formatter & Validator
Paste a .feature file to pretty-print it with consistent indentation and aligned tables, catch structural mistakes with line numbers, and preview every scenario a Scenario Outline generates from its Examples.
Private by design: anything you enter is processed in your browser only. It is never uploaded to or logged on our servers. Share links carry the feature text inside the link itself.
Click a line number to jump to it in the input.
About Gherkin feature files
Gherkin is the plain-language format behind behaviour-driven development (BDD). A .feature file describes one capability of the system as a set of concrete examples written in Given / When / Then steps, and frameworks such as Cucumber (Java, JavaScript, Ruby), SpecFlow and Reqnroll (.NET), Behave (Python) and Karate bind each step to automation code. Because product owners, testers and developers all read the same file, keeping it tidy and consistent matters as much as keeping code formatted.
The formatter rewrites your file with consistent indentation (2 or 4 spaces, or tabs), normalized keyword casing and spacing, one blank line between scenarios, and table columns padded so every pipe lines up. Escaped pipes (\|) and other escapes inside cells are preserved, doc strings (""" or ```) keep their content and relative indentation, and comments stay where they were. Nothing about the meaning of the file changes, so the formatted output is safe to commit.
The validator reports problems with line numbers: content before the Feature: line, steps outside a scenario, a Scenario Outline without Examples, <placeholders> that have no matching Examples column (and columns no step uses), table rows with the wrong number of cells, unclosed doc strings, duplicate or empty scenarios, scenarios that start with And or But, and a When that follows a Then (usually a sign that one scenario tests two behaviours). Only English keywords are recognised; a # language: header for another language is reported instead of being guessed at.
The Outline preview tab expands every Scenario Outline into the concrete scenarios your test runner will execute, substituting each Examples row into the name, steps, data tables and doc strings. It is a quick way to check that every row produces sensible steps. To pick which combinations of inputs deserve a row, use the pairwise test generator, and fill data tables with realistic values from the mock data generator. When your step definitions need stable element locators, the E2E locator generator suggests them for Playwright, Cypress and Selenium.
Reference Guide
Gherkin keywords (English):
| Keyword | Synonyms | Purpose |
|---|---|---|
Feature: | none | One per file. A name plus optional free-text description |
Rule: | none | Groups scenarios that illustrate one business rule (Gherkin 6+) |
Background: | none | Steps run before every scenario in the Feature or Rule |
Scenario: | Example: | One concrete example made of steps |
Scenario Outline: | Scenario Template: | A template run once per Examples row, with <placeholders> |
Examples: | Scenarios: | Data table for an outline; the first row is the header. An outline may have several, each with its own tags |
Given / When / Then | * (bullet) | Context / action / expected outcome |
And / But | none | Continue the previous step type; purely for readability |
| | none | Data table row; escape a literal pipe as \|, a backslash as \\ and a newline as \n |
""" or ``` | none | Doc string: multi-line text passed to the step, optionally with a media type such as """json |
@tag | none | Tags before Feature, Rule, Scenario, Scenario Outline or Examples |
# | none | Comment (whole line only). # language: fr on the first line switches the keyword language |
Tag usage. Tags are inherited: a tag on the Feature applies to every scenario, a tag on a Rule to the scenarios inside it, and a tag on Examples only to the scenarios generated from that table.
| Goal | Example |
|---|---|
| Run a subset (Cucumber JS) | npx cucumber-js --tags "@smoke and not @wip" |
| Run a subset (Cucumber JVM) | mvn test -Dcucumber.filter.tags="@smoke or @regression" |
| Run a subset (SpecFlow / Reqnroll) | dotnet test --filter Category=smoke (tags become test categories) |
| Scope a hook to tagged scenarios | Java @Before("@db"), JS Before({ tags: '@db' }, fn) |
| Mark work in progress / flaky | @wip, @flaky, excluded in CI with not @wip |
| Link to a ticket | @JIRA-1234 (tags cannot contain spaces) |
Background or a Before hook?
| Background | Before hook | |
|---|---|---|
| Visible to readers | Yes, written in the feature file | No, lives in code |
| Scope | Every scenario in its Feature or Rule | Every scenario, or those matching a tag expression |
| Order | After Before hooks, before the scenario's own steps | First, before any Background step |
| Best for | Business context a reader needs ("Given I am signed in as an admin") | Technical setup: database reset, browser launch, test data, mocks |
| Keep it | Short (around four steps or fewer) | Fast and side-effect free between scenarios |
Good practice: write declarative steps that describe behaviour, not imperative UI scripts.
| Avoid | Prefer | Why |
|---|---|---|
When I click the "#login-btn" button | When I sign in with valid credentials | Survives UI changes; selectors belong in step code |
Given I fill "email" with "a@b.com" And I fill "password" with … | Given I am signed in as a premium customer | States intent, hides incidental detail |
| Several When / Then pairs in one scenario | One behaviour per scenario | A failure points to one rule |
Then the database row has status = 2 | Then the order is marked as shipped | Observable outcome in domain language |
| Long Background shared by unrelated scenarios | Split the feature, or move setup into hooks | Readers should not scroll to understand a scenario |
| Scenario names like "Test 1" | Unique names that state the rule being shown | Reports and duplicates are easy to read |
Example input
@checkout
Feature: Checkout
Scenario Outline: Apply a discount code
Given my cart contains "<sku>"
When I apply the discount code "<code>"
Then the total is <total>
Examples: Valid codes
| sku | code | total |
| WH-1000 | SAVE10 | 224.99 |
| EB-200 | FLAT5 | 74.00 |
This sample loads automatically when you open the tool. Use Load Sample to bring it back.
Frequently Asked Questions
It normalises indentation and keyword spacing, aligns data table columns and separates scenarios with blank lines. The meaning of your steps is not changed.
Missing Feature lines, steps outside scenarios, Scenario Outlines without Examples, placeholders missing from the Examples table, table rows with the wrong number of columns and duplicate scenario names.
Cucumber, SpecFlow and Reqnroll, Behave, pytest-bdd and many other BDD frameworks read Gherkin feature files.
Related Tools
All QA & Testing Tools →E2E Locator Generator
Paste an HTML snippet and get robust locators for Playwright...
Pairwise Test Case Generator
Generate a minimal set of test cases that covers every pair...
OpenAPI Validator & Viewer
Validate OpenAPI 3.x and Swagger 2.0 specs in YAML or JSON,...
Throughput Estimator
Estimate requests per second, peak load, bandwidth and the n...
Conventional Commit & Changelog Generator
Write Conventional Commits messages with a guided builder an...
Image Format Converter
Convert images between PNG, JPG, WebP, GIF, BMP, TIFF, ICO,...