Use a browser WebSocket tester to connect to your endpoint, send a known message, and inspect the reply. It's a quick way to check a message contract without starting your application. The browser still controls the handshake, so custom authorization headers and protocol-level inspection may require a different client.
The WebSocket Tester I link to below is one I built. I tried 3 alternatives that required either a local installation or handwritten connection code, which felt excessive for checking one reply. It uses the browser's WebSocket API, so you don't need to install a client or upload a capture file to make a connection. If you have a better one, tell me.
On September 8, 2026, I tried to check a WebSocket endpoint with fetch() and got HTTP 426 back. The service was running. My request simply wasn't asking for the connection upgrade the endpoint expected.
I opened the application that normally used the socket, signed in, and clicked through to the screen that triggered a subscription. By the time I could inspect the reply, I'd dragged application state into a question that should have taken one connection to answer: does this subscription message still work?
A dedicated websocket tester makes that question smaller. You enter the endpoint, establish a connection, and send the same payload the application would send. If the server rejects it, you can inspect that response without wondering whether a component effect changed the payload first.
My first test is usually deliberately boring. One subscription. One topic. One expected acknowledgment.
Suppose your application sends {"action":"subscribe","topic":"orders"}. Before testing real order updates, check whether the server acknowledges the subscription at all. A successful connection only confirms that the handshake completed. Your application protocol may still require an authentication message before accepting subscriptions.
I also write down what success means before connecting. "Something appeared in the log" is a weak check. "The reply contains the requested topic and an accepted status" gives you something concrete to compare after a backend change.
Keep the first payload small enough to read without scrolling. A 47-field production message creates too many places to hide a typo. Once the smallest accepted message works, add the optional fields that matter to the bug.
This is where a browser client earns its place: short, interactive checks where you need direct control over each message. You can pause between sends and follow an unexpected response immediately.
The WebSocket Tester uses the native browser WebSocket API to connect to ws:// or wss:// endpoints. It supports working with messages in JSON, text, or hex, depending on what you're testing.
Underneath the interface, a connection starts with a WebSocket object. The browser performs the opening handshake and reports when the socket becomes ready. Sending before the open event is an error, which explains a surprising number of broken console snippets.
Here's a complete browser-console example using Postman's public echo endpoint. Run it from an ordinary HTTPS page whose Content Security Policy permits that connection. The endpoint is an external service, so availability and your network rules still apply.
The sequence value gives you an easy way to recognize your own message. An echo proves that this payload made a round trip to that endpoint. It doesn't prove that your own service accepts the same message or that a subscription will keep delivering events.
Change the URL to test your service, then replace the payload with something its protocol understands. An application server probably won't echo arbitrary input. You need to judge its response against its own contract.
First, JSON isn't a separate WebSocket wire format. Calling send() with the result of JSON.stringify() sends a text message. The server decides whether to parse that text as JSON. A JSON editor can help you avoid syntax errors, but valid JSON can still contain an invalid application message.
Hex needs similar care. The string "0a" consists of two text characters. A binary message containing byte 0x0a contains one byte. If you're investigating a binary protocol, verify whether the tool's selected mode sends decoded bytes or literal text. A hex display alone doesn't settle that question.
Second, the browser exposes complete messages to JavaScript. A server may split a message across multiple WebSocket frames, and the browser reassembles it before delivering a message event. A UI might label its entries "frames," but a native browser client isn't a raw view of every frame on the connection.