# debugger-protocol-viewer: the reference browser for the Chrome DevTools Protocol

> The Chrome DevTools Protocol Viewer is the official web viewer for CDP, a zero dependency client side application that renders protocol domains, methods, events and types directly from the protocol JSON at runtime. It publishes three targets, Tip-of-Tree, Stable 1.3 and the V8 Inspector for Node.js, and it preserves the old permalink structure.

**ChromeDevTools/debugger-protocol-viewer** — Website for viewing the DevTools Protocol as defined in Chromium

- Repository: https://github.com/ChromeDevTools/debugger-protocol-viewer
- Website: https://chromedevtools.github.io/devtools-protocol/
- Stars: 896 · Forks: 187
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/chromedevtools-debugger-protocol-viewer

## The protocol source of truth lives in Chromium, not here

The Chrome DevTools Protocol Viewer is the official web viewer for the Chrome DevTools Protocol, published at chromedevtools.github.io/devtools-protocol/. It is maintained under the ChromeDevTools organisation, and the package metadata names Google Inc. as the author.

The important thing to understand is where the protocol actually comes from. The readme is explicit that the protocol source of truth is defined in the Chromium codebase, with a link to source.chromium.org pointing at third_party/blink/public/devtools_protocol/ in the Chromium tree. The protocol definitions themselves live in a different repository, ChromeDevTools/devtools-protocol, and that is also where the deployments happen.

So the flow is: Chromium defines the protocol, the devtools-protocol repository holds the JSON definitions, and this viewer renders them. That chain explains the whole design of the site. A viewer that read a hand written HTML export would need regenerating whenever a domain changed. This one does not, because the rendering happens at runtime from the protocol JSON.

The practical consequence for anyone using the site is that the content you read is exactly what Chromium currently implements, including domains and members that no released browser has yet shipped. That is the feature for tool authors, since the protocol you need is often a week or a month ahead of the browser you can install, and it is the trap for anyone assuming everything listed is available today.

The licence is Apache 2.0, stated in the readme with a LICENSE file at the root, though the licence field on the repository itself says Other because GitHub cannot classify it.

## Runtime rendering means no regeneration when the protocol changes

The architecture section is short and every line in it is a design decision.

The application is a zero-dependency vanilla client-side application built with modern web standards. No framework, no runtime dependency beyond what the browser already provides.

The first feature is dynamic runtime rendering. Protocol domains, methods, events and types are rendered dynamically from protocol JSON at runtime, and the readme says explicitly that no template regeneration or manual navigation edits are needed when new domains or members land in Chromium.

The second is an isomorphic protocol core. Data normalization, member sorting, stabilization and route parsing live in src/protocol-model.js, and the point is that it is fully testable in Node.js without DOM dependencies. That is what makes the unit tests run in under 50 milliseconds, since the core logic does not need a browser to be exercised.

The third is type cross-references. Native reverse-dependency analysis, shown as a Used by link, dynamically links every protocol type to the commands, events and types that reference it. If you are working out which command accepts a given type, or which event will carry it, this is the fastest route to an answer.

The fourth is multi-target support, with instant switching between Tip-of-Tree, which is the latest, Stable 1.3, and the V8 Inspector for Node.js, via a left navigation target switcher. The V8 Inspector target is the one people forget exists, and it is the reference for the subset of CDP that Node.js implements, which is not the whole protocol.

Two smaller features are worth a line. Instant global search uses the / or Cmd+K shortcut for fuzzy search across domains, methods, events and types. And legacy URL preservation is handled with static HTML stubs at /tot/<Domain>/index.html plus a wildcard fallback at /404.html, which the readme says ensures 100 percent backward compatibility for existing permalinks across the web.

## Building it locally with pnpm and serving on port 8696

The local development path is three commands, and the build is the part that usually surprises people because it is not a bundler.

Dependencies first.

```sh
pnpm install
```

Then the build.

```sh
pnpm run build
```

The readme describes what that does, and the description is the interesting part. It builds the production distribution in devtools-protocol/ and generates backward-compatible static redirect stubs. Looking at the scripts in package.json makes the mechanism clearer: build runs node scripts/generate-stubs.js, and there is a separate prep step running bash prep-tot-protocol-files.sh, which is the part that pulls the protocol definitions in.

Then serve it.

```sh
pnpm run serve
```

That runs node scripts/serve.js, and you open http://localhost:8696/devtools-protocol/ in your browser. The port is fixed rather than randomised, which is the sort of small decision that makes the documentation useful.

The package manifest sets the type to module, so the scripts are ES modules, and the engines field requires Node 22.0.0 or newer. There is a.nvmrc and an.npmrc in the repository root.

The dependency list is deliberately thin. The devDependencies are @types/node, the devtools-protocol package itself at a caret range, and typescript at 7.0.2. The devtools-protocol dependency is the protocol JSON, consumed as a package rather than fetched by hand, which is what makes the prep step reproducible.

The repository layout follows the same logic: src/ for the application, data/ for the protocol data, scripts/ for the build and serve scripts, types/ for the type declarations, and test/ for the tests.

## The test suite drives headless Chrome over CDP itself

The testing section is the most self-referential and most convincing part of the project, because the viewer for the Chrome DevTools Protocol tests itself by driving Chrome with the Chrome DevTools Protocol.

The project uses Node's native test runner, node:test, for unit, stub integrity and end-to-end testing.

```sh
pnpm run preflight
pnpm test
pnpm run test:unit
pnpm run test:stubs
pnpm run test:e2e
```

The preflight target is the full gate: typecheck, lint, format check and tests. The individual targets split the suite into isomorphic core unit tests, which run in under 50 milliseconds, stub generator integrity tests, and the end-to-end browser tests.

The end-to-end tests are the notable ones. They launch headless Chrome with --remote-debugging-port=0 and communicate directly over native WebSockets via the Chrome DevTools Protocol, validating route navigation, legacy hash redirects, target switching, search shortcuts and in-domain quick jump pills.

That list of covered behaviours maps exactly onto the features described earlier, which is what you want from a suite like this: the legacy URL stubs, the target switcher and the search shortcut are all things that could silently regress, and each is exercised through the same protocol the site documents.

The scripts in package.json map onto the same structure, with test running typecheck then test:node, test:node running node --test over the test files matching the test glob, and each of test:unit, test:stubs and test:e2e pointing at a single file. The typecheck is tsc --noEmit with a tsconfig.json in the root, so the JavaScript is type checked without being compiled.

## Where the viewer is the wrong tool

The first limit is that it is documentation, not a client. The site tells you what a CDP command takes and what it returns. It does not open a connection, it does not send commands and it does not give you a session. If your goal is to script a browser, you need an actual CDP client library, and this viewer is the specification you write that library against.

The second limit is the Tip-of-Tree target. It tracks Chromium main, which means domains, commands and events appear there before they exist in any browser you can install. That is precisely what you want when you are building against a protocol that has not shipped, and precisely what misleads you when you are debugging against Chrome stable. The stable 1.3 target is the one to read when the question is what you can use today, and the difference between the two is often the difference between a working script and a method that returns an error.

The third is the V8 Inspector target, which covers the subset of CDP that Node implements rather than the whole protocol. Commands that exist in the Chromium protocol may not exist for Node, and the viewer lists them together, so a command listed in the Node target has to be read carefully rather than assumed available.

The fourth is the search being fuzzy rather than structured. It finds a domain or a method by name, but there is no filter for, say, every command that takes a particular parameter type across the whole protocol. The Used by reverse dependency view on a type page is the tool for that kind of question, and you need to know it is there.

The alternative approach for most people is the JSON definition file itself, which is machine readable and is what you would consume from your own client. The viewer wins when a human needs to understand the shape of the protocol, particularly the type relationships and the per-target differences. A tool author who needs to enumerate everything programmatically should read the definitions and use the viewer to understand what the definitions mean.

## Conclusion

This viewer is the reference to keep open while writing any tool that speaks CDP, because it is generated from the same protocol definitions Chromium uses rather than from a hand maintained copy, and it is the only place that shows the type level reverse dependencies between commands. It is not a debugging client in itself, so it will not replace a CDP library in your project, and the Tip-of-Tree target changes with every Chromium commit, which means anything you read there may not exist in the browser you are actually driving. Before relying on it, check the target selector in the left navigation and read the entry for the stable 1.3 protocol if you need to ship against a released Chrome.

## FAQ

### What is the Chrome DevTools Protocol Viewer?

It is the official web viewer for the Chrome DevTools Protocol, published at chromedevtools.github.io/devtools-protocol/. It is a zero-dependency vanilla client-side application that renders protocol domains, methods, events and types dynamically from the protocol JSON at runtime.

### Where does the Chrome DevTools Protocol definition come from?

The protocol source of truth is defined in the Chromium codebase, in third_party/blink/public/devtools_protocol/, with the JSON definitions held in the ChromeDevTools/devtools-protocol repository, which is also where the deployments to the published site happen through GitHub Actions.

### How do I build and serve the debugger-protocol-viewer locally?

Run pnpm install, then pnpm run build to produce the distribution in devtools-protocol/ and generate the backward-compatible redirect stubs, then pnpm run serve and open http://localhost:8696/devtools-protocol/. Node 22 or newer is required.

### Which protocol targets can I switch between in the viewer?

Tip-of-Tree, which is the latest, Stable 1.3, and the V8 Inspector for Node.js, switched instantly from a target switcher in the left navigation. The Tip-of-Tree target tracks Chromium main and so can list members no released browser has yet.

### How are the debugger-protocol-viewer end-to-end tests run?

They launch headless Chrome with --remote-debugging-port=0 and communicate directly over native WebSockets via the Chrome DevTools Protocol, validating route navigation, legacy hash redirects, target switching, search shortcuts and in-domain quick jump pills. The unit and stub tests use Node's native test runner, node:test.

## Sources

- [ChromeDevTools/debugger-protocol-viewer on GitHub](https://github.com/ChromeDevTools/debugger-protocol-viewer)
- [Issues](https://github.com/ChromeDevTools/debugger-protocol-viewer/issues)
- [Project website](https://chromedevtools.github.io/devtools-protocol/)
- [README](https://github.com/ChromeDevTools/debugger-protocol-viewer/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chromedevtools-debugger-protocol-viewer