WebSocket Tester

What is WebSocket?

WebSocket is a two-way connection that stays open between the browser and the server. Over HTTP every exchange starts with its own request and ends when the reply arrives; with WebSocket the connection is made once and either side can send a message whenever it likes. The server does not have to wait to be asked before it says something -- this is how live data flows without constant polling.

The connection begins as an ordinary HTTP request. The client sends an Upgrade: websocket header; if the server accepts it answers 101 Switching Protocols and the same TCP connection speaks the WebSocket protocol from then on. So WebSocket is not a separate service replacing HTTP but an upgrade that starts over it, which is also why nothing beyond ports 80 and 443 has to be opened.

Addresses are written ws:// or wss://. wss:// is the WebSocket equivalent of HTTPS and is encrypted with TLS; ws:// is not. Because an encrypted page may not open an unencrypted connection, ws:// over HTTPS works only for addresses on your own machine, and a remote server needs wss://.

Where it is typically used:

Chat and instant messaging, typing indicators
Live prices, scores and dashboard feeds
Collaborative editing and shared cursors on one document
Server-pushed notifications and job status updates
State synchronisation in multiplayer games

Not every live-data problem needs WebSocket. If data only flows from server to client, Server-Sent Events are simpler: an ordinary HTTP response that reconnects on its own and gives proxies less trouble. WebSocket earns its place where the client also has to talk back, continuously and with low latency.

How to test a WebSocket

Enter the address

Enter the endpoint you want to test as wss://, or a server on your own machine as ws://localhost:PORT. If the server expects a subprotocol, put it in the field beside it; separate several with commas.
Connect and read the warning

Press Connect and your own browser opens the connection. If the address is a ws:// one that an HTTPS page cannot reach, the tool says so before it tries, so a request the browser blocked is never mistaken for a server fault.
Send messages, read what comes back

Write your text or JSON and send it, formatting it as JSON first if you like. Every frame in and out is listed with a timestamp, a size and a type; binary frames appear as a hex summary.
Inspect the close code and the latency

When the connection drops, the close code and its meaning are printed: 1000 a normal closure, 1006 an abnormal network-level drop, 1011 a server error. Against an echo server you can also measure the round-trip time, and you can download the whole log as JSON.

Why is ws:// blocked on an HTTPS page?

This page is served over HTTPS. Browsers do not let an encrypted page open an unencrypted connection; that is what mixed content means. The rule covers WebSockets too: if you try to reach a remote server over ws:// from an HTTPS page, the request is cancelled by the browser before it ever reaches the network. Even when there is nothing wrong with your server.

Loopback is the one exception. Browsers treat localhost and 127.0.0.1 as trustworthy because the traffic never leaves the machine, so ws://localhost:8080 reaches a server running on your own computer without trouble. Firefox aligned its behaviour with Chrome's here.

So to test a remote server from this page, that server has to serve TLS and the address has to be wss://. The tool spots the case as you type and warns you before it tries to connect, so you are not left hunting for a bug that is not in your code.

Address	Result from this page
`wss://example.com/socket`	Works. Encrypted connection, no mixed-content problem.
`ws://localhost:8080`	Works. Loopback addresses count as trustworthy.
`ws://127.0.0.1:8080`	Works. The same exception covers the IPv4 loopback address.
`ws://example.com/socket`	The browser blocks it. The tool says so before trying to connect and suggests the wss:// equivalent.

Close codes: why did the connection drop?

When a WebSocket closes, the browser hands you a number. That number is usually the whole answer: a 1000 means you can stop looking, a 1006 means the problem is in the network or a proxy in between rather than in your application logic. The tool prints the code and what it means for every connection that closes.

Code	What it means	What to do
`1000`	Normal closure	Nothing is wrong. One side finished its work and closed cleanly.
`1001`	Going away	The tab was closed or the server is restarting. This is where reconnection logic belongs.
`1006`	Abnormal closure	No close frame arrived. Look at the network, a firewall, a reverse-proxy timeout or a crashed process. It leaves no trace in the application layer.
`1008`	Policy violation	Usually authentication. Check the token, the headers and the cookies sent during the handshake.
`1009`	Message too big	You exceeded the server's frame size limit. Split the message or raise the limit.
`1011`	Internal server error	The fault is on the server. Read the server logs; there is nothing to change on the client.
`4000-4999`	Application-defined	The service you connect to defines the meaning and documents it. You can use this range in your own protocol.

Key features

Your browser makes the connection

There is no proxy in between. The address, the subprotocol and the messages never reach Coderspace; they flow only between your tab and the server.

Mixed-content warning

Type a remote ws:// address on an HTTPS page and it warns you before trying to connect, so a connection the browser blocked is never mistaken for a server fault.

Close code with its meaning

When the connection drops it prints the code, the reason text from the server and what the code means.

A log with direction, type and size

Every frame is listed with its direction, timestamp, byte size and type. Binary frames are not mangled into broken text; they appear as a hex summary.

Round-trip time

Against an echo server it takes five measurements in a row and reports the minimum, average and maximum latency in milliseconds.

Reconnect with backoff

When the connection drops unexpectedly it retries with a doubling delay. Enough to watch for the moment the server comes back.

FAQ

Why can't I connect to a ws:// address from an HTTPS page?

Browsers do not let an encrypted page open an unencrypted connection — that is mixed content, and the rule covers WebSockets too. Try to reach a remote server over ws:// and the request is cancelled before it reaches the network, even when your server is perfectly fine. Loopback is the one exception: ws://localhost and ws://127.0.0.1 work, because the traffic never leaves the machine. For a remote server the address has to be wss://, and the tool tells you that before it even tries to connect.

My connection closes with code 1006 — what does that mean?

1006 means no close frame ever arrived: the connection was not closed, it broke. The cause is almost always outside your application code — a network drop, a firewall, a reverse-proxy timeout (nginx, ALB, Cloudflare) or a crashed server process. The code does not come from the server; the browser makes it up itself, which is why there is no reason text either. For idle connections, ping/pong or an application-level keepalive clears up most 1006 cases.

Do my messages and the address reach Coderspace servers?

No. Your browser opens the connection; there is no proxy or relay on the Coderspace side. The address you type, the subprotocol and every message you send flow only between your tab and the server — they never touch us and are never logged. That is also why you can reach an address only you can see from this page, such as ws://localhost:8080 or a server on your local network.

How does the round-trip measurement work?

The tool sends five short text messages one after another and waits for each to come back unchanged; what it measures is the gap between sending and receiving. So the measurement only makes sense against an echo server that returns what it was given. If you have your own protocol, the messages will not be echoed and nothing comes back, and the tool says "no reply came back". It does not use the WebSocket protocol's own ping/pong frames, because browser JavaScript has no access to them.

What goes in the subprotocol field?

The name your server expects — graphql-ws, mqtt or wamp.2.json, for example. Separate several options with commas; the browser offers them all during the handshake and the server picks one. Once connected, the tool prints which one the server chose. Leave the field empty if your server does not expect a subprotocol: offering one it does not know can make some servers reject the handshake outright.

What is the difference between ws:// and wss://?

They are the same protocol; the difference is the transport. ws:// runs unencrypted over plain TCP, wss:// runs over TLS — exactly the relationship http has with https. A wss:// connection also travels over port 443, so it has an easier time with proxies and firewalls. Outside local development wss:// is in practice the only right choice, and it is the only one that works from an HTTPS page anyway.

Send a message

Message log

What is WebSocket?

How to test a WebSocket

Enter the address

Connect and read the warning

Send messages, read what comes back

Inspect the close code and the latency