## TL;DR
WebdriverIO can drive Chrome either through the DevTools protocol directly (devtools automation) or through the standard WebDriver protocol via chromedriver (webdriver automation). Devtools mode gives you CDP superpowers (network interception, performance tracing, deeper page control) with less setup, but it is Chrome/Chromium-only. Webdriver mode is the cross-browser, standards-based path and what you want for a grid or multi-browser matrix. Pick devtools for Chrome-only debugging-heavy suites; pick webdriver when you need Firefox, Safari, or a Selenium Grid.

## The query
```text
webdriverio devtools vs webdriver protocol: which to use
```

## Use this when
- Starting a WebdriverIO project and choosing `automationProtocol`
- You need CDP features like request interception
- Deciding whether to keep chromedriver in your stack
- Moving a Chrome-only suite toward cross-browser coverage

## Not for
- Choosing between WebdriverIO and Playwright/Cypress
- WebdriverIO installation or config basics
- Appium mobile automation protocol questions

## Steps
1. List your hard requirements: browsers needed, grid usage, CDP features (network mocking, tracing). Expected output: a short requirements list that clearly favors one mode.
2. If Chrome-only plus CDP needs, set `automationProtocol: 'devtools'`; otherwise use `'webdriver'` with the appropriate driver service. Expected output: config reflects the chosen protocol and sessions start successfully.
3. Port any protocol-specific commands (CDP-only commands do not exist in webdriver mode and vice versa). Expected output: the suite runs without "unknown command" errors.
4. Run the suite and confirm stability and feature coverage (e.g. interception actually intercepts). Expected output: green run with the CDP or cross-browser features you required actually working.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kVezwQO0BF8JT7taR1XTOw