WebSocket Connection Tester
Open a ws:// or wss:// connection, send messages and read every frame and close code.
Heads-up: this is the one TinyToolz tool that uses the network.
Your browser opens the WebSocket to the URL you type, straight from this tab. Nothing is proxied and no message is sent to TinyToolz.
Must start with ws:// or wss://. Nothing is filled in for you,
and no URL is contacted until you press Connect. Want to see the tool work first? Tap
to fill the field with a public echo server — nothing is contacted until you press Connect.
Subprotocols (optional)
Not connected
Frame log
Nothing yet. Enter a URL and press Connect: every open, message, error and close frame lands here with a timestamp.
WebSocket close codes (RFC 6455 section 7.4.1 and the IANA registry)
| Code | Name | Meaning | Copy |
|---|---|---|---|
| 1000 | Normal Closure | The connection completed normally: the purpose it was opened for has been fulfilled. | |
| 1001 | Going Away | An endpoint is disappearing — a server shutting down, or a browser navigating away from the page. | |
| 1002 | Protocol Error | The endpoint is closing because the peer committed a protocol error. | |
| 1003 | Unsupported Data | The endpoint received a frame of a type it cannot accept, for example binary data on a text-only endpoint. | |
| 1004 | Reserved | Reserved. No meaning is defined, so it must never be sent. | |
| 1005 | No Status Received | Reserved for applications: no status code was actually present in the close frame. It is never sent on the wire. | |
| 1006 | Abnormal Closure | Reserved for applications: the connection dropped without a close frame. This is what you see when the handshake fails, the host is unreachable or the TCP connection is cut. It is never sent on the wire. | |
| 1007 | Invalid Frame Payload Data | A text frame did not contain valid UTF-8, or the payload was otherwise inconsistent with the message type. | |
| 1008 | Policy Violation | The message violated a policy. A generic code for when 1003 and 1009 do not fit, or when the real reason should stay hidden. | |
| 1009 | Message Too Big | The message was larger than the endpoint is willing or able to process. | |
| 1010 | Mandatory Extension | The client expected the server to negotiate one or more extensions and the server did not. Sent by clients only. | |
| 1011 | Internal Error | The server hit an unexpected condition and cannot finish the request. Sent by servers only. | |
| 1012 | Service Restart | The server is restarting. Registered with IANA, not defined in RFC 6455 itself. | |
| 1013 | Try Again Later | The server is overloaded or rate limiting; retry after a delay. Registered with IANA. | |
| 1014 | Bad Gateway | A gateway or proxy got an invalid response from the upstream server. Registered with IANA. | |
| 1015 | TLS Handshake | Reserved for applications: the TLS handshake failed. It is never sent on the wire. | |
| 3000-3999 | Registered library codes | Reserved for libraries, frameworks and applications that register a code with IANA. Available to the WebSocket API. | |
| 4000-4999 | Private use | Free for private agreement between client and server. Available to the WebSocket API, so this is the range your own app should use. |
How it works
Type a ws:// or wss:// endpoint and press Connect: your browser
performs the RFC 6455 opening handshake itself through the standard WHATWG WebSocket API.
Every event is timestamped in the frame log, including the open, each text or binary frame
in either direction, any error, and the close frame with its code, its RFC 6455 name and the
reason string the server sent. Sent and received frames show their UTF-8 byte length, so you
can see what a payload actually costs on the wire, and if you request subprotocols the log
records which one the server picked.
This is the only tool on TinyToolz that touches the network, and the connection runs strictly
between your own browser and the server you name. There is no relay, no proxy and no account,
and your URL, your messages and the log never leave this tab. Two limits are worth knowing.
Browsers deliberately hide why a handshake failed, so a failure surfaces as close code
1006 with no detail; check the scheme, the host, the port and whether the server
requires wss:// or a permitted Origin. And because this page is
served over HTTPS, plain ws:// URLs are blocked as mixed content by the browser
rather than by us, so the tool warns you before it tries. Ping and pong frames are handled
inside the browser and are never exposed to JavaScript, so they cannot appear in the log.
Frequently asked questions
How do I test a WebSocket connection?
Paste your endpoint in the URL box, add any subprotocols you need, and press Connect. Your browser performs the RFC 6455 opening handshake itself and the frame log fills up with timestamped events: the open, every text or binary frame in either direction, any error, and the close frame with its code and reason. Type into the message box and press Send, or Ctrl+Enter, to push a text frame; each sent and received frame shows its UTF-8 byte length. Nothing is contacted until you press Connect, and no URL is filled in for you.
What does WebSocket close code 1006 mean?
Code 1006 is Abnormal Closure, defined in RFC 6455 section 7.4.1 as reserved for applications: the connection dropped without a close frame ever arriving, so there is no status from the server to report. It is never sent on the wire, and browsers deliberately hide why a handshake failed, so a wrong host, a wrong port, a refused connection, a rejected Origin or a TLS problem all look identical from JavaScript. Check the scheme first, then the host and port, then whether the server requires wss:// or an allow-listed Origin. The full close code table, including the 3000-3999 registered range and the 4000-4999 private range your own app should use, is on the page.
Is my WebSocket URL or my messages sent to TinyToolz?
No. This is the one TinyToolz tool that uses the network at all, and the connection runs straight from your own browser tab to the host you type. There is no relay, no proxy and no account, so your URL, your tokens and your payloads never reach our servers, and the log stays in the page until you clear it. One consequence of running in a browser: because this page is served over HTTPS, plain ws:// URLs are blocked as mixed content by the browser itself, so use wss:// for anything that is not on localhost. Ping and pong frames are handled inside the browser and are never exposed to JavaScript, so they cannot appear in the log.