Toolvore

WebSocket Tester

Test WebSockets with text or binary messages, subprotocols, close diagnostics and log export.

Your browser connects directly to the endpoint you enter, not through Toolvore. Messages are queued for that server; a queued message is not proof of delivery. Test only an endpoint you are authorized to use, and review exported logs before sharing them.

Connect to a chosen WebSocket endpoint, send text, validated JSON or binary bytes, and download bounded message and close diagnostics.

How to use it

  1. 1Enter an authorized ws:// or wss:// endpoint and optional subprotocols, then connect.
  2. 2Choose text, JSON, hex or Base64 and explicitly send a message.
  3. 3Review queued and received payload bytes, negotiated protocol and chronological previews.
  4. 4Disconnect and inspect the close event; review the log before downloading or sharing it.

Example

Input
Text: Hi 👋
Output
7 queued payload bytes; an unchanged echo is 7 received bytes.

A chosen echo endpoint must return the original text; sending alone does not confirm delivery.

What happens to your data

Messages go directly from your browser to the endpoint you choose, whose logging policies apply. Toolvore does not proxy the socket. The explicit JSON export includes the URL and retained messages, possibly including secrets. Page state is not saved in browser storage.

Last updated October 2026

Open a browser WebSocket connection to an endpoint you choose, exchange text or binary messages, and inspect a chronological diagnostic log. The URL starts blank, and connecting requires an explicit click. Optional subprotocols are offered in the order you enter them; the connection panel shows the protocol and extensions actually negotiated by the browser and server.

Use text for an exact string, JSON to validate a message without rewriting it, or hex and Base64 to send binary bytes. The counters distinguish messages queued for sending from messages received. A JSON download contains the current session details, retained previews, byte totals and any observed close event, so a debugging note can preserve its limitations alongside its evidence.

How it works

Enter an absolute ws:// or wss:// URL with no fragment or embedded username/password. The tester accepts up to 4,096 URL characters and 16 unique comma-separated subprotocol tokens within 1,024 characters. Tokens are case-sensitive. These are optional application protocols, not HTTP headers. Connection attempts stop waiting after 10 seconds; Cancel connection stops the attempt sooner. There is no automatic retry or reconnect.

Text and JSON are sent as UTF-8. JSON is parsed only to validate syntax: the original text is sent, preserving whitespace, number spelling, large integer literals and duplicate keys. This does not establish that the server accepts your application schema. Hex accepts complete byte pairs and ASCII whitespace. Base64 accepts canonical standard alphabet and padding, with ASCII spaces and line breaks; URL-safe Base64 and data URLs are rejected. Both binary modes send decoded bytes, and received binary messages appear as a hex preview. Empty text or binary messages are permitted.

Each outbound payload is limited to 256 KiB. A send is refused if it would raise the browser's pending queue above 1 MiB. The queued byte count measures payload accepted by send(), not delivery or application acknowledgment. Received text uses UTF-8 bytes; binary uses its exact byte length. Neither count includes WebSocket framing, compression, TLS or other network overhead. Totals use exact integer arithmetic and are exported as decimal strings.

The log keeps the newest 200 entries and at most 256 KiB of preview text, with a 4 KiB UTF-8 preview ceiling per entry. It displays entries oldest first. A long binary message has fewer payload bytes visible because each byte needs two hex digits and separators. Removed entries and truncated previews are explicitly counted in the page and download. Counters cover the session even when previews are dropped. Clear log removes retained entries and resets the log-disclosure counts, while preserving traffic counters. A new connection starts a fresh log and fresh counters. These limits bound retained previews, not the browser's incoming network buffers; this tool is not a high-volume or stress tester.

Disconnect can request code 1000 or a custom code from 3000 through 4999 with a reason of up to 123 UTF-8 bytes. The final diagnostic reports the close event's code, reason and wasClean value. If the close handshake has not completed after five seconds, logging stops and the page explicitly says no close event was observed. The browser may continue finishing its network shutdown. A clean close does not prove that an application processed previously queued messages. Leaving the page detaches callbacks and requests closure.

The connection goes directly from your browser to your chosen server; Toolvore does not proxy the payload. A secure page generally needs wss://. The server sees the browser Origin, and cookies follow browser and server policies. The native browser API does not offer custom Authorization headers, client certificate selection, raw ping frames or a way to bypass TLS or Origin checks. Socket.IO is a separate application protocol and is not interchangeable with a plain WebSocket connection. Handshake failures often expose only a generic browser error, so server logs may be needed.

The endpoint, including query values, and retained message previews are included in the explicit JSON download. Keep credentials out of test messages and review an export before sharing it. Page state is not saved in browser storage, but downloaded copies remain on your device and the remote endpoint controls its own logging and retention.

Worked example: UTF-8 payload versus character count

Input
Text message: Hi 👋
Result
Queued payload: 7 bytes; an exact text echo adds 7 received bytes.

This assumes your server echoes the text unchanged. A real server can transform, reject or ignore it; queued does not mean acknowledged.

Common use cases

  • Checking a development endpoint's plain WebSocket handshake and subprotocol choice
  • Sending a JSON fixture without rounding a large numeric literal
  • Comparing binary hex bytes with the response from an echo server
  • Saving bounded connection and close diagnostics for a bug report

Frequently asked questions

Does this WebSocket tester connect automatically?+

No. The URL is empty initially. Enter your own authorized endpoint and press Connect. There is no built-in public echo connection, automatic send or reconnect loop.

Can I add an Authorization header?+

The browser WebSocket API does not expose arbitrary request headers. Use the endpoint's documented browser-compatible authentication flow. Query tokens may be visible in server logs and this tool's export, so do not assume they are private.

Why can a wss:// connection fail even with a valid URL?+

TLS, a firewall, authentication, an unsupported subprotocol or the server's Origin rules may reject it. The generic browser error does not identify which one occurred. Check the server's own diagnostics; this page cannot bypass those checks.

Does JSON mode preserve large numbers and duplicate keys?+

Yes. It validates syntax but sends your original string. The tool does not stringify the parsed object, so literal spelling and duplicate keys remain in the outgoing message. How the receiving application interprets them is separate.

Is the downloaded log a full packet capture?+

No. It contains retained application-message previews and diagnostics, not handshake headers, wire frames or all historical message content. Size limits, removed-entry counts and preview-truncation flags are included. Full payload byte totals remain separate from retained previews.