websocket-devtools and the WebSocket panel that keeps listening

Monitoring that survives closing the panel

WebSocket DevTools is a browser extension that adds a WebSocket DevTools tab to the developer tools of Chrome and Edge, and the feature at the centre of it is background monitoring. The description says it plainly: the extension continuously monitors connections even when the DevTools panel is closed, and the pro tip in the quick start makes the same point. If you open DevTools after a WebSocket is established, you will not miss the connections that were already there.

That is the gap it fills. The browser's own network tooling shows WebSocket frames for connections it observed, but a connection that was established before you opened the inspector, or one that opened while the panel was closed, is history you cannot get back. In a chat application or a real time game, where the connection is usually opened at page load and the interesting traffic happens later, that difference decides whether you can debug the session at all.

The rest of the feature list is arranged around the same idea of taking control of a live connection. Message simulation sends custom messages in both directions, client to server and server to client. Traffic control lets you block messages and simulate network issues. The favorites system saves frequently used messages so you do not retype them. There is a JSON viewer with full parsing and formatting, and iframe support, described as full WebSocket proxy support for iframe embedded connections, which covers the case of a page that embeds another origin's socket client.

The audience is a frontend or full stack developer working on a real time application, a socket.io based chat, or a web game, and the topics list confirms the range, with socket.io, webgame, real-time-chat and websocket-client among them.

Simulation and blocking are the same capability seen from two sides

The demo section of the README shows two gifs, one for blocking and one for simulation, and the key features list groups them: message blocking intercepts and blocks WebSocket messages in real time, message simulation sends custom messages to test different scenarios, traffic control manages WebSocket traffic flow for debugging, and there is full JSON parsing and formatting support.

It is worth being clear about what this means technically, because the two capabilities are more powerful together than separately. A socket client usually reacts to the shape of a message rather than its content, so a test that only reads traffic tells you what the server sent but not how the client behaves. With simulation, you can send the message the server would have sent under a different condition, a reconnection, a permission denial, a different user state, and watch the UI react, without a staging server that produces that condition on demand.

Blocking is the same mechanism pointed the other way. If a client hangs on a message it does not understand, blocking that message type tells you so immediately, and the favourites system exists to make the repeated version of that experiment cheap, since a message you blocked once is usually a message you will block again in the next test.

The honest caveat is that all of this is a client side intervention. The extension sees the traffic of the browser it is installed in, and it can change what the page receives and what the server receives, but it does not change the server's behaviour, and anything the page does outside the socket is untouched.

Installing from a store, or unpacking a ZIP by hand

There are three installation routes and they are described in enough detail to be followed without guessing.

On the Chrome Web Store, you visit the listing, click Add to Chrome and confirm, and then open DevTools with F12 and look for the WebSocket DevTools tab. On Microsoft Edge the same three steps apply through the Edge Add-ons site, with the button labelled Get instead of Add to Chrome.

The manual route exists for people who cannot or prefer not to use a store. You download the ZIP attached to the latest GitHub release, extract it, open chrome://extensions or edge://extensions, enable Developer mode, choose Load unpacked and select the extracted folder.

The warning under that section is the one to remember: manual installations do not update automatically, and you have to check the Releases page for newer versions. An unpacked extension is a directory on your disk that the browser loads, so there is no update mechanism at all, and a developer who installs it once in January is running January's code in November. For a tool that sits in the path of live traffic and can inject messages, that is worth remembering when something behaves oddly.

The project also hosts a homepage at websocket-devtools.com with documentation and demos, and a demo video on YouTube, and the README is translated into Simplified Chinese, Traditional Chinese and Japanese.

The build generates Chrome locales before Vite runs

The package manifest is a JavaScript project built with Vite, and the scripts are where the interesting detail is.

"build": "npm run clean && node scripts/generate-chrome-locales.js && vite build"

"dev": "node scripts/generate-chrome-locales.js && vite build --watch --mode development"

Every build, production or development, runs a script that generates the Chrome locale files before Vite is invoked, and the build script clears the dist directory first. That is a specific pattern worth understanding rather than copying blindly. A Chrome extension declares its translations in a _locales directory with a particular layout, and rather than checking generated locale files into the repository, the project generates them at build time from a single source, which is why the i18n script exists as a separate command as well.

The rest of the toolchain is small. The test script is node --test, which uses the test runner built into Node rather than a framework, the preview script is vite preview, and the clean script removes the dist directory. The package is an ES module, the package manager is pnpm at 10.5.2, and the engines field requires Node at ^20.19.0 or >=22.12.0 with pnpm at 8.0.0 or newer. The dependencies are dominated by CodeMirror, with the commands, JSON language, search, state and view packages plus a one dark theme, which is the message editor and the JSON viewer.

There is a test/ directory and a test-high-traffic.html file at the root, which is the kind of fixture a project adds when it needs to exercise the capture path against a busy connection rather than a quiet one.

A dependency override is the clearest statement of priorities

Buried in the manifest is a pnpm override that is worth more attention than its size suggests:

"pnpm": {
  "overrides": {
    "shell-quote": "1.9.0"
  }
}

An override pins a transitive dependency to a specific version, whatever the ranges in the dependency tree would otherwise allow. In this case it is shell-quote, a transitive dependency pinned to version 1.9.0.

The fact that it is in the manifest rather than in a discussion thread is the point. A reviewer, or a user checking whether the extension is safe to install, can see the pin in the file that defines the dependency tree, and the same file states the privacy posture in plain terms: no data collection, everything stays in your browser, local storage only with no external servers or tracking, open source and auditable, and minimal permissions, only what is needed for functionality. There is a PRIVACY.md and a SECURITY.md in the repository, and the README says to follow SECURITY.md to report a vulnerability privately.

For an extension that can read and rewrite the traffic of every site you visit, that combination, a visible dependency pin plus a written privacy policy, is more than most extensions of this kind offer.

Favourites, JSON formatting and the iframe case

Three smaller features carry a lot of the daily usefulness, and they are worth separating from the headline capabilities.

The favorites system saves and organises frequently used messages, which is what turns message simulation from a one-off experiment into a workflow. The screenshots section gives it its own panel for the smart favorites system, and the design of the interface is not incidental in a tool whose users are developers looking at traffic all day.

The JSON support is the other one. The message details view has a JSON viewer with full parsing and formatting, and the simulation side has a JSON editor, which means a crafted message is a document you can write and validate rather than a string you concatenate. For a protocol where the payload is structured, that is the difference between experimenting with a real object and guessing at escaping.

The iframe support is the edge case that shows the author has met the real problem. A page that embeds another origin's socket client, a third party chat widget, a payment iframe, has its traffic in a frame that does not obviously belong to the page you are debugging. The README describes the feature as full WebSocket proxy support for iframe embedded connections, which is a meaningful capability rather than a cosmetic one.

Together with background monitoring, those three features are what make the extension usable on a real application rather than on a test page you wrote yourself.

MIT, three languages of documentation, and releases every week

The licence is MIT, with the text in the LICENSE file at the root of the repository, and the manifest agrees. The author is Brian Luo, and the project is published under the law-chain-hot organisation.

The release record shows a fast cadence. Version 1.4.0 was published on 2026-09-19, 1.3.0 on 2026-09-12 and 1.2.0 on 2026-09-05, so three releases in two weeks with a week between them, and the repository is not archived with the last push on 2026-09-28.

That tempo has an implication for a browser extension, because extension stores have their own review timelines and a version that is in the repository may not be in the store yet. The badge in the README is at 1.4.0, matching the newest release, and the version link points at the releases page.

The repository itself is a normal extension project with a src/ directory, a scripts/ directory, icons/, a ScreenShot/ directory with the interface images, the three translated READMEs, and the governance files, CONTRIBUTING.md, SECURITY.md and PRIVACY.md, with a separate wiki and a DeepWiki link for extended documentation.

For a user the practical advice is short. Install from the store so the browser handles updates, keep the panel open when you need live injection, and treat the background monitor as the reason to install it at all, because that is the one thing the browser's own tooling will not do for you.

Editorial conclusion

Adopt websocket-devtools if you debug WebSocket applications in Chrome or Edge and need to see frames from connections that were already open, to send crafted messages in either direction, or to block traffic on demand. Do not adopt it if you need a system wide capture outside the browser, since it is an extension and it only sees the traffic of the browser it is installed in. Verify three things first: that you install it from the Chrome Web Store or the Edge Add-ons site rather than an unpacked release, since a manual install does not update itself, that the permissions it requests match what you expect, and that the traffic you are about to block or fake is a test environment, because the extension can both intercept and inject. The last push was on 2026-09-28 and the newest release is v1.4.0 from 2026-09-19.

Frequently asked questions

Official sources

1. law-chain-hot/websocket-devtools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases