{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}: {{ badge.value }}
Use an endpoint you are authorized to test. The browser sends its normal Origin and cookies; it cannot add arbitrary handshake headers.
Send only content permitted by the endpoint owner. Evidence records size only unless payload previews are enabled.
Optional comma-separated names in preference order. The server may select at most one.
ms
From 1,000 to 30,000 milliseconds.
Close after recording 1–500 sent or received messages.
bytes
Close after 1,024–1,048,576 cumulative message bytes.
Off by default. Turn this on only when copied evidence may safely include message content.
{{ record_payload_previews ? 'Include previews' : 'Sizes only' }} 
{{ transcriptText }}

The chart renderer is unavailable. The same event counts remain available in the ledger.

TimeEventBytesElapsedEvidenceCopy
{{ row.time }}{{ row.event }}{{ row.bytes }}{{ row.elapsed }}{{ row.evidence }}
WebSocket Connection Capacity Calculator Size a WebSocket node pool from peak connections and measured per-node limits with bottleneck, N+ reserve and scale-out checks.
Application Programming Interface (API) Testing Tool Test HTTP APIs from your browser with cURL import and authentication while inspecting exposed headers, timing, response text and CORS failures.
TLS Handshake Trace Trace a live TLS handshake to review protocol and cipher, certificate identity and trust, plus DNS-to-negotiation timing from one remote probe.
SSL Checker Check a public hostname across SSL Labs endpoints for weak protocols and trust gaps, then prioritize certificate renewal and TLS fixes.

A WebSocket begins as an HTTP opening handshake and, after the server accepts the upgrade, becomes a long-lived two-way message connection. The browser and server can then send messages independently without creating a new HTTP request for every update. Chat, live dashboards, presence, collaboration, and streaming status feeds commonly use this pattern.

Connection success proves that the browser completed the handshake with that endpoint at that moment. It does not prove that the application protocol is correct, authentication will remain valid, every message type works, or an intermediary will keep an idle connection open. Sending a small authorized message and observing the reply or close event supplies stronger evidence than an open event alone.

Endpoint
A wss:// address for a TLS-protected remote connection, or a local ws:// address during development.
Origin
The web origin sent by the browser. Servers often check it before accepting browser clients.
Subprotocol
An application protocol name offered by the client. The server may select at most one offered value.
Close code
A numeric reason category from the closing exchange or the browser's report of an abnormal end.

Browser tests have a deliberate security boundary. The page sends the browser's normal Origin and applicable cookies, but script cannot attach arbitrary handshake headers. A server that expects a custom header may work with a command-line client and still reject a browser connection. Browser error events also hide many handshake details, so server, proxy, TLS, and network logs remain important.

A bounded test prevents an unexpectedly noisy endpoint from filling the page with evidence. Message-event and cumulative-byte limits stop the session after enough traffic has been observed. Payload previews stay off unless message content is safe to retain and share.

Only test endpoints you own or have permission to assess. A WebSocket message can trigger real application actions, and cookies may authenticate the browser automatically. Use non-destructive payloads, avoid secrets, and disconnect as soon as the required evidence is collected.

How to Use This Tool:

Start with an authorized endpoint and conservative evidence limits, then send the smallest message that proves the intended application exchange.

  1. Enter a complete WebSocket endpoint. Use wss:// for remote hosts; insecure ws:// is accepted only for localhost, 127.0.0.1, or [::1].
  2. Enter up to 10 unique Subprotocols in preference order when the endpoint requires them. Leave the field empty when the application does not negotiate a subprotocol.
  3. Set Connection timeout, Message event limit, and Recorded byte limit. Short diagnostic sessions usually need much less than the maximum values.
  4. Leave Payload previews off when sizes, timing, event direction, and close evidence are enough. Turn it on only when copied or downloaded evidence may safely contain message excerpts.
  5. Connect explicitly and wait for Connection is open. If the attempt fails before opening, check the URL, certificate, Origin policy, proxy upgrade handling, authentication flow, and server logs.
  6. Enter an authorized Text message and send it while the connection is open. Observe sent and received events, then disconnect normally when the test is complete.

Interpreting Results:

An OPEN entry confirms that the browser accepted the server's handshake and records elapsed time plus the selected subprotocol, if any. OUT and IN entries show message direction and byte size. They prove browser-observed traffic, not the server's internal processing result.

A CLOSE entry should be read with its code, reason, and clean-close flag. Code 1000 normally accompanies a deliberate normal close. Code 1006 is a browser-side indication that no usable close frame was received; it is not a close code transmitted on the wire. A clean flag describes the closing exchange as observed by the browser, not application-level success.

LIMIT means the configured message or byte ceiling was reached and the connection was closed to bound evidence collection. Increase a limit only when the endpoint owner expects more traffic and retaining it serves a defined diagnostic purpose.

A generic connection failure does not identify whether DNS, TCP, TLS, HTTP upgrade handling, Origin policy, authentication, subprotocol negotiation, or an intermediary caused the rejection. Correlate the attempt time with authoritative logs before assigning a cause.

Technical Details:

The browser WebSocket interface validates the opening response, exposes open, message, error, and close events, and handles WebSocket framing below the page. The evidence model records what the browser can observe rather than reconstructing hidden handshake fields or network packets.

Mechanism Core:

Stage Protocol or browser action Evidence retained Interpretation boundary
Validate requestCheck scheme, host, credentials, fragment, subprotocol tokens, and bounds before connecting.No transcript on invalid inputLocal validation does not contact the endpoint.
OpenThe browser sends an HTTP upgrade request with its Origin, cookies, and offered subprotocols.Safe endpoint, elapsed milliseconds, and selected subprotocolArbitrary handshake headers cannot be added by the page.
ExchangeText is sent only while the socket is open; incoming text or binary messages raise message events.Direction, elapsed time, and encoded byte size; optional bounded text previewReceipt does not prove application-side persistence or processing.
LimitIncoming traffic that reaches the event limit or would exceed the byte limit triggers a bounded close.A limit event followed by closing evidenceThe transcript is intentionally incomplete after the ceiling.
CloseEither side starts the closing exchange, or the connection ends abnormally.Close code, reason, elapsed time, and clean-close flagSome failures expose only a generic browser error.

Rule Core:

Setting or value Accepted rule Effect
EndpointAt most 2,048 characters; no URL credentials or fragmentQuery values are redacted in retained endpoint evidence.
Remote transportwss:// required outside localhostTLS protects confidentiality and integrity in transit.
Subprotocols0 to 10 unique valid protocol tokensThe server may select one offered token.
Connection timeout1,000 to 30,000 milliseconds, inclusiveThe pending attempt is stopped at the chosen limit.
Message events1 to 500 sent or received messagesCounts traffic in both directions for the bounded session.
Recorded bytes1,024 to 1,048,576 cumulative message bytesIncoming traffic that would exceed the limit closes the connection.
Outgoing messageAt most 65,536 encoded bytes and within the remaining session limitsOversized text is rejected before sending.
Payload previewOff by default; text excerpts collapse whitespace and stop at 160 charactersBinary payload content is not previewed.

Byte size is measured from UTF-8 encoding for text. Received binary data is counted from the browser-provided byte length. Times are elapsed milliseconds from the current connection attempt, while event timestamps use UTC ISO 8601 strings.

No Formula Core is used because the governing work is a protocol event sequence plus validation rules, not an equation. Event counts and byte totals bound the transcript; they do not calculate connection quality or server health.

Privacy and Safety Notes:

The connection runs directly from the browser to the entered endpoint. Session evidence remains in page memory unless you copy or download it. Normal browser cookies and Origin behavior still apply to the connection.

  • Do not test endpoints without authorization or send destructive application messages.
  • Keep payload previews off for secrets, personal data, tokens, or confidential application content.
  • Query values are redacted from retained endpoint text, but message previews and close reasons may still reveal sensitive information.
  • Close the page or start a fresh attempt to clear the current in-memory transcript.

References: