How does the W3C WebDriver protocol work?

The W3C specification standardised what was previously the JSON Wire Protocol. Every interaction is a request to a REST-like endpoint on the driver or Grid. The response includes a status value, the command result and error information. Bindings are convenience wrappers over these endpoints.

POST /session
Content-Type: application/json

{
  "capabilities": {
    "alwaysMatch": {
      "browserName": "chrome",
      "platformName": "linux"
    }
  }
}

HTTP/1.1 200 OK

{
  "value": {
    "sessionId": "a1b2c3",
    "capabilities": {
      "browserName": "chrome",
      "browserVersion": "128.0"
    }
  }
}

• Session commands create, query and delete a session
• Navigation commands handle back, forward, refresh and URL changes
• Element commands find, click, send keys and read attributes
• Script commands execute JavaScript and manage timeouts
• Cookie, window and alert commands cover browser state
• The newer WebDriver BiDi work adds bidirectional browser events alongside the classic protocol

Capabilities are the contract. alwaysMatch must match exactly, while firstMatch offers alternatives. A Grid uses them to pick a node, and a cloud provider uses them for billing and routing. Mismatched capabilities cause session creation errors rather than silent fallbacks.

ChromeOptions options = new ChromeOptions();
options.setBrowserVersion("stable");
options.addArguments("--headless=new");

WebDriver driver = new RemoteWebDriver(
    new URL("http://grid.example.com:4444"),
    options);