Enter a WebSocket endpoint to connect, exchange text messages and inspect connection events. Traffic goes directly to that endpoint; browser security rules and server origin checks can prevent a connection.
Enter a ws:// or wss:// address, press Connect WebSocket, and the log below shows each step: the address it opens, the moment the connection is ready, everything you send, and every frame the server returns. The browser connects from your device straight to that endpoint; voritools.com is only the page you are looking at.
The Example button fills the field with wss://echo.websocket.org, a public echo service that sends every message straight back, so the whole round trip can be checked without your own server.
A normal close reports code 1000. Code 1006 means the handshake never completed: the port was closed, the host was unreachable, the TLS certificate was rejected, or the server refused the browser's origin. The log prints that code instead of leaving an empty error line.
Browsers do not expose the reason for a failed handshake, so the code is the most precise signal the page can get. For a server on your own machine, check that it is really listening on the port you typed.
WebSocket connections are not subject to CORS, but a server can inspect the Origin header, and this page sends https://voritools.com. A server that whitelists origins refuses the handshake, and the browser then reports code 1006.
Because the page itself is HTTPS, plain ws:// is accepted only for localhost and 127.0.0.1. Everything else has to be wss://; otherwise the browser blocks the connection before it starts and the page says so.
Frames are printed as escaped text: if a server echoes HTML back, the tags appear literally instead of being rendered into the page, and the same is true for the messages you send.
The log is a running transcript, not a terminal: it shows text frames, it keeps nothing after a reload, and Clear removes it.