QA & Testing Tools

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.

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):

KeywordSynonymsPurpose
Feature:noneOne per file. A name plus optional free-text description
Rule:noneGroups scenarios that illustrate one business rule (Gherkin 6+)
Background:noneSteps 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 / ButnoneContinue the previous step type; purely for readability
|noneData table row; escape a literal pipe as \|, a backslash as \\ and a newline as \n
""" or ```noneDoc string: multi-line text passed to the step, optionally with a media type such as """json
@tagnoneTags before Feature, Rule, Scenario, Scenario Outline or Examples
#noneComment (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.

GoalExample
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 scenariosJava @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?

BackgroundBefore hook
Visible to readersYes, written in the feature fileNo, lives in code
ScopeEvery scenario in its Feature or RuleEvery scenario, or those matching a tag expression
OrderAfter Before hooks, before the scenario's own stepsFirst, before any Background step
Best forBusiness context a reader needs ("Given I am signed in as an admin")Technical setup: database reset, browser launch, test data, mocks
Keep itShort (around four steps or fewer)Fast and side-effect free between scenarios

Good practice: write declarative steps that describe behaviour, not imperative UI scripts.

AvoidPreferWhy
When I click the "#login-btn" buttonWhen I sign in with valid credentialsSurvives 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 customerStates intent, hides incidental detail
Several When / Then pairs in one scenarioOne behaviour per scenarioA failure points to one rule
Then the database row has status = 2Then the order is marked as shippedObservable outcome in domain language
Long Background shared by unrelated scenariosSplit the feature, or move setup into hooksReaders should not scroll to understand a scenario
Scenario names like "Test 1"Unique names that state the rule being shownReports 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.