Skip to content

WebSocket Tester Online (ws/wss Client)

Test a WebSocket from your browser: connect to ws:// or wss://, send text, JSON or real binary frames from HEX/Base64, read binary messages as HEX, and see close codes with reasons. Messages go straight to your server, not ours.

Runs in Browser Free
Your browser sends messages straight to the server you enter — they do not pass through go-tools servers.
Fill in: (third-party echo service: availability not guaranteed, and your messages go to that third party)
Not connected

Messages appear here. No WebSocket connection is opened until you press Connect.

Timed send (application heartbeat)
ms

This sends an ordinary text message on a timer. It is not a protocol-level ping frame — web pages cannot send or see ping/pong frames. Off by default, because a server that does not expect it may close the connection.

Connection, text and binary messages, close codes, handshake failures, connection timeout, the Socket.IO handshake, heartbeat, reconnect and a 10,000-message flood are tested end to end against a local WebSocket server; browser behaviour described on this page was measured in Chromium, Firefox and WebKit in October 2026. — Go Tools Team · Oct 13, 2026

Built and verified by the Go Tools engineering team.

WebSocket tester quick answers

Can this HTTPS page connect to ws://localhost?

Yes in Chrome after you allow local network access It depends on the browser (as of October 2026). Chrome 147 and later first asks whether the page may access devices on your local network; after you choose Allow, ws://localhost and ws:// to a LAN IP address connect. Firefox connects to localhost directly but blocks LAN addresses. Safari blocks ws:// from HTTPS pages.

Why does a failed connection only say 1006?

The browser hides the reason When the handshake fails, browsers are required to give the page only error and close code 1006 — never the HTTP status or reason. Press F12: the Chrome and Edge console shows the status code the server returned.

Can I add an Authorization header?

Browsers cannot set headers No. The browser WebSocket API has no way to set request headers. Put the token in a URL parameter, a subprotocol or a cookie — whichever your server accepts.

Is the heartbeat a ping frame?

It is an ordinary message No. Web pages cannot send or see protocol-level ping/pong frames; the browser answers server pings by itself. Timed send here is an ordinary text message on an interval, and it is off by default.

Why can't I connect to a Socket.IO server?

Use the Socket.IO preset Socket.IO is not plain WebSocket. Choose the Socket.IO preset: it connects to /socket.io/?EIO=4&transport=websocket, replies 40 to the open packet and answers each ping 2 with pong 3 (Socket.IO v3/v4).

What is an online WebSocket tester?

A WebSocket tester is a client you point at a WebSocket server to see whether it accepts a connection and what it sends back. You enter a ws:// or wss:// address, connect, send text or binary messages and read the replies — the quickest way to check a backend endpoint, a reverse proxy or a device that speaks WebSocket without writing client code.

This tester runs in your browser: the connection goes straight from your browser to the server you enter, and messages do not pass through go-tools servers. That also means it has the browser's limits. It cannot add custom request headers, it cannot send protocol-level ping frames, and when a handshake fails the browser tells the page only close code 1006, not why.

What it adds over a bare browser console: binary messages shown as HEX (or Base64) and sent from HEX or Base64 as real binary frames, JSON formatted automatically, close codes explained, a checklist when a connection fails, a warning before connecting when the browser is likely to block the address, and a log that stays responsive at about 2,000 messages per second (measured).

09:30:01.204 · Connecting to ws://localhost:8080/ws
09:30:01.219 · Connected · subprotocol: chat
09:30:02.517 → TXT 17 B {"type":"hello"}
09:30:02.531 ← TXT 25 B {"type":"hello","ok":true}
09:30:03.002 → BIN 4 B 48 69 00 FF
09:30:03.010 ← BIN 4 B 48 69 00 FF
09:30:09.880 · Closed · code 4001: application-defined code

Features of the WebSocket tester

Localhost and LAN: per-browser guidance before you connect

Before you connect, the tool checks the address: a plain ws:// to a domain name from this HTTPS page will be blocked, so it says so and suggests wss://. For localhost and LAN IP addresses it tells you Chrome will ask for local network access, and how Firefox and Safari differ (as of October 2026).

Binary messages as HEX, real binary sends

Received binary messages are shown as HEX, 16 bytes per line, or as Base64. Type bytes as 48 69 00 FF, 0x48,0x69 or Base64 and they go out as a binary message; invalid characters and odd digit counts are reported with their position, and the byte preview shows exactly what will be sent.

Close codes and failures you can act on

Every close shows the code, the reason text and whether the closing handshake completed, with the meaning of standard codes 1000–1015 and a note for 4000–4999 application codes. A failure before the connection opens produces a checklist instead of a guess.

Fast log with search and export

Messages are drawn once per frame, so the page stays responsive at about 2,000 messages per second in our tests. Each entry has direction, millisecond timestamp, type and byte size. Filter by direction, search, pause the view, keep the last N entries, copy or export as text.

Subprotocols, timeout, Socket.IO preset

Request one or more subprotocols (comma-separated) and see whether the server confirmed one. A connection timeout ends handshakes the server never answers. The Socket.IO preset completes the Engine.IO v4 handshake and answers pings for you.

Opt-in heartbeat and reconnect

Timed send repeats a message of your choice at an interval, and auto-reconnect retries with exponential backoff after an unexpected drop. Both are off by default, and the tool never sends anything you did not ask for.

WebSocket test examples: localhost, binary, close codes, Socket.IO

Test a local development server

ws://localhost:8080/ws
Connected
→ TXT 17 B {"type":"hello"}
← TXT 25 B {"type":"hello","ok":true}

In Chrome 147 and later the browser first asks whether to allow access to your local network; choose Allow. Firefox connects to localhost directly; Safari blocks ws:// from this HTTPS page (as of October 2026).

Send a binary message from HEX

48 69 00 FF
→ BIN 4 B 48 69 00 FF

In HEX mode the tool sends a binary message with these four bytes, not the text 48 69 00 FF. Base64 SGkA/w== sends the same four bytes.

Read a server close

Server closes with code 4001, reason "token expired"
Closed · code 4001: application-defined code · clean close
Reason: token expired

Codes 4000–4999 are defined by the application, so look up 4001 in the server's documentation. Codes 1000–1015 are standard and are explained in the log.

Connect to a Socket.IO server

Protocol: Socket.IO v3/v4, address ws://localhost:3000
Connecting to ws://localhost:3000/socket.io/?EIO=4&transport=websocket
← 0{"sid":"…","pingInterval":25000,…}
→ 40
← 40{"sid":"…"}

The preset fills in the Socket.IO path and query, replies 40 to join the default namespace and answers each ping 2 with 3. Send events as 42["event","data"].

How to test a WebSocket online

  1. 1

    Enter the server address

    Type or paste a ws:// or wss:// address; http:// and https:// are treated as ws:// and wss://. Check the note under the address: it warns when the browser is likely to block it.

  2. 2

    Add subprotocols if the server needs them

    Some servers require a subprotocol, for example mqtt. Enter one or more, comma-separated. After connecting, the log shows which one the server confirmed.

  3. 3

    Connect

    Press Connect. For localhost or a LAN address in Chrome, choose Allow when asked about local network access. If the connection fails, follow the checklist that appears.

  4. 4

    Send and read messages

    Choose Text, HEX or Base64, check the preview and press Ctrl+Enter. Received JSON is formatted and binary is shown as HEX; switch binary to Base64 in the log toolbar.

  5. 5

    Filter, then copy or export

    Filter by direction or search the log, pause the view during a flood, then copy or export the log as text with timestamps, direction and byte sizes.

Common WebSocket connection mistakes

ws:// to a domain name from an HTTPS page

Browsers block unencrypted ws:// to a domain name from a page loaded over HTTPS (mixed content). Chrome and Firefox refuse at once with a SecurityError. Use wss://; for a LAN server in Chrome, write its IP address (local network access must be allowed).

✗ Wrong
ws://api.example.com/ws
✓ Correct
wss://api.example.com/ws

HEX typed in text mode

In text mode 48 69 is sent as the text characters 4, 8, space, 6, 9. Switch to HEX to send the bytes 0x48 0x69 as a binary message.

✗ Wrong
Text mode: 48 69 → TXT 5 B
✓ Correct
HEX mode: 48 69 → BIN 2 B

Socket.IO URL used as plain WebSocket

A Socket.IO server rejects a plain WebSocket at its root path, and without replies to its handshake and pings it closes the connection. Use the Socket.IO preset.

✗ Wrong
ws://localhost:3000
✓ Correct
ws://localhost:3000/socket.io/?EIO=4&transport=websocket

Token in a request header

Browsers cannot send an Authorization header with a WebSocket handshake. If your server allows it, pass the token as a URL parameter or a subprotocol instead.

✗ Wrong
Authorization: Bearer eyJ…
✓ Correct
wss://api.example.com/ws?token=eyJ…

When an online WebSocket tester helps

Checking a backend endpoint
Confirm a new WebSocket route answers, inspect the first messages it sends and test how it handles malformed input — before the frontend exists.
Debugging a reverse proxy
Behind Nginx or a gateway, see whether the upgrade gets through and how long an idle connection survives.
IoT and binary protocols
Devices and brokers that speak binary over WebSocket can be read as HEX and sent exact bytes from HEX or Base64.
Reproducing close codes
See the close code and reason the server actually sends, for example when a token expires or a client is rate-limited.
Watching high-volume message streams
Watch a server push about 2,000 messages a second (measured) without freezing the page, with counters for messages and bytes.

How WebSocket connections work in the browser

The opening handshake
A WebSocket starts as an HTTP request with Upgrade: websocket. The browser builds the request headers itself — Origin, Sec-WebSocket-Key, Sec-WebSocket-Version: 13 and Sec-WebSocket-Protocol from the subprotocol list — and the page cannot add others. The server answers 101 Switching Protocols, and from then on both sides exchange messages.
Text and binary messages
send() with a string sends a text message encoded as UTF-8; send() with bytes sends a binary message. Pages receive whole messages, never frames, fragments or masks. This tool sets binaryType to arraybuffer so binary messages arrive in order and can be shown as HEX.
Why errors carry no detail
The WebSocket standard forbids browsers from telling scripts why a connection failed — DNS failure, refused port, certificate error or HTTP 401 all look the same — so a page cannot probe your local network. Pages see an error event and close code 1006 (Firefox reports certificate errors as 1015).
Mixed content and local network access
An HTTPS page may not open unencrypted ws:// to a public host. Since Chrome 147, WebSocket also falls under Local Network Access: reaching localhost or a private IP from a public page needs your permission. Firefox exempts loopback addresses; Safari does not (as of October 2026).
Close codes
A client may close only with 1000 or 3000–4999, and the reason may be at most 123 bytes of UTF-8. 1005 (no status code) and 1006 (abnormal closure) never appear on the wire; the browser reports them. 1015 is reported for TLS failures by some browsers only.

WebSocket testing tips

Use wss:// outside your machine
Encrypted wss:// with a trusted certificate reaches public servers from this page in every browser and protects tokens in the URL; for localhost or LAN addresses, Chrome still asks for local network permission first. Keep plain ws:// for localhost.
Check the console when the handshake fails
The page only sees 1006. Chrome and Edge print the HTTP status in the console, which usually points straight at authentication, path or proxy problems.
Allow the Origin on the server
Browsers always send Origin. If your server checks it, allow https://go-tools.org while testing; CORS headers do not apply to WebSocket.
Let the server send pings
To keep idle connections alive through proxies, have the server send ping frames; the browser answers them automatically. Use timed send only if your protocol expects an application message.
Keep tokens out of shared logs
Addresses often carry tokens. The tool keeps the address and messages only in memory, but exported logs and screenshots include them — remove secrets before sharing.

WebSocket tester FAQ

Can I test ws://localhost or a LAN server from this HTTPS page?
It depends on the browser (as of October 2026). Chrome 147 and later treats WebSocket connections to your computer or local network as local network access: the first time, it asks whether to allow this site, and after you choose Allow, ws://localhost, ws://127.0.0.1 and ws:// to a LAN IP address such as 192.168.1.10 connect. In Chrome the LAN server must be written as an IP address; a plain host name (other than .local) is blocked even if it resolves to your network. Firefox connects to localhost directly but blocks ws:// to LAN addresses. Safari blocks ws:// to localhost and the LAN from HTTPS pages. wss:// is not affected by the mixed-content rule: public servers work from this page in every browser as long as the certificate is trusted; for localhost or LAN addresses, Chrome asks for local network permission first here too.
Why can't I connect to ws://example.com from this page?
This page is served over HTTPS, and browsers block an unencrypted ws:// connection to a public host from an HTTPS page (mixed content). Chrome and Firefox refuse immediately with a SecurityError, which the tool reports. Use the server's wss:// address. Public sites served over plain http do not have this rule, but in recent Chrome they cannot reach localhost or your LAN at all.
The connection failed with code 1006 — what went wrong?
1006 only means the connection ended without a closing handshake. When a handshake fails, the WebSocket standard requires the browser to hide the cause from the page — a 401, a 404, a refused port, a certificate error and a rejected Origin all look identical (Firefox reports certificate errors as 1015) — so no web tester that connects straight from the browser can show it. Press F12 and open the Console: Chrome and Edge print the HTTP status the server returned. The tool also separates failures before the connection opened from drops after it was open and lists the usual causes for each.
Can I add an Authorization or other custom header?
No. The browser WebSocket API does not let web pages set request headers; the browser sends a fixed set (including Origin and cookies for the server's own site). Common workarounds, depending on what your server supports: a token in the URL, such as wss://host/ws?token=…; a token passed as a subprotocol (only token characters are allowed, so JWT works but standard Base64 with = or / does not, and the server must echo the subprotocol back); or a cookie, which browsers send reliably only to the page's own site, so from this page it usually does not reach your server. Tools such as Postman can set headers because they are not browsers.
Why does it work in Postman but not here?
Postman and command-line clients can set any header and usually send no Origin. A browser cannot add an Authorization header and always sends Origin: https://go-tools.org. If the server needs a header token or checks Origin, it rejects the browser's handshake; allow the Origin or pass the token another way.
Does the heartbeat send WebSocket ping frames?
No. Web pages can neither send nor see protocol-level ping/pong frames; when the server sends a ping, the browser answers with a pong by itself. Timed send here sends an ordinary text message, such as {"type":"ping"}, at the interval you set. It is off by default because a server that does not expect that message may close the connection. To keep an idle connection alive through a proxy, have the server send pings.
Why can't I connect to my Socket.IO server?
Socket.IO is a protocol on top of WebSocket, not plain WebSocket. A Socket.IO v3/v4 server expects the path /socket.io/?EIO=4&transport=websocket, sends an open packet starting with 0, expects 40 to join the default namespace, and closes the connection if each ping 2 is not answered with pong 3. Choose the Socket.IO preset and the tool does all of this; then send events as 42["event","data"]. Servers configured for HTTP long-polling only will not accept a WebSocket at all.
My connection drops after about a minute — why?
Usually an idle timeout in a reverse proxy. Nginx closes a proxied connection when no data passes for 60 seconds by default (proxy_read_timeout), and the page sees code 1006. Raise the timeout or have the server send ping frames. Behind Nginx, also make sure the proxy forwards the upgrade with proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; (before Nginx 1.29.7, also proxy_http_version 1.1;).
How do I connect to a wss:// server with a self-signed certificate?
Open https://the-same-host:port/ in a new tab, accept the certificate warning, then come back and connect. The browser remembers the exception for that host and port. Only do this for your own test servers, because it lowers the browser's protection.
How do I send and read binary messages?
Choose HEX or Base64 as the send format. HEX accepts 48 69 00 FF, 0x48,0x69 or 486900FF; the preview shows the bytes, and invalid characters or an odd number of digits are reported with their position instead of being sent. Received binary messages are shown as HEX, 16 bytes per line, and the log toolbar switches them to Base64. To read received HEX as text, paste it into Hex to String.
Do my messages go through go-tools servers?
No. Your browser connects directly to the address you enter, and messages do not pass through our servers. The tool also opens no WebSocket connection until you press Connect, and it keeps the address and messages only in memory — not in the page URL or browser storage. Like the rest of the site, this page loads analytics and advertising scripts.
Is there a server I can test against?
Use the local echo: it runs inside this page, echoes everything you send and makes no network connection. Public echo services such as wss://echo.websocket.org/ also exist, but they are third-party: availability is not guaranteed, and your messages go to that third party.

Related Tools

View all tools →