WebSocket URL Validator
Check an absolute ws, wss, http, or https URL against WebSocket constructor URL rules, excluding fragments. HTTP schemes are accepted by the constructor and mapped to WebSocket schemes.
Description
Check whether an absolute URL meets WebSocket scheme, host, and fragment rules, and understand what a valid result establishes.
WebSocket lets a client and server exchange messages over an ongoing connection. An opening handshake is the exchange in which the client requests a WebSocket session and the server accepts it. Once established, either side can send messages without the client making a new request for each update. This is useful for chat, collaborative applications, and live dashboards. The connection needs an endpoint URL that identifies the server and the application resource to contact.1
A WebSocket address commonly starts with ws:// or wss://. Transport Layer Security (TLS) protects traffic in transit. The ws scheme does not provide TLS encryption, while wss carries the WebSocket connection over TLS. In wss://example.com:8443/chat?room=blue, example.com is the host, 8443 is the explicit port, /chat is the resource path, and room=blue is a query parameter. The path and query help the server select the intended endpoint or session.
A fragment is the portion of a URL introduced by #, such as #messages. It is separate from the path and query, so inspect this component when copying an address from a page.2
WebSocket URL Validator checks the address before a connection attempt. It accepts a parsable absolute URL with a host, one of the supported schemes, and no fragment. Its boolean result describes those URL checks. Whether the server exists, accepts a WebSocket handshake, or permits the requested session requires a separate connection test.
When to check a WebSocket address
Use this check when configuring an endpoint, reviewing a copied address, or separating an address problem from a connection failure. A false result directs attention to the URL itself; a true result lets you move on to the server, network, and application requirements.
- Check that a configured endpoint includes a supported scheme and a host.
- Identify a fragment accidentally copied from a browser address or documentation link.
- Check an HTTP or HTTPS address that will be passed to the browser's WebSocket constructor.
- Validate endpoint syntax in a repeatable workflow without opening a network connection.
How WebSocket URL validation works
- Paste the complete endpoint address into WebSocket URL, including its scheme and host.
- Run the validator.
- Read the Valid result.
- If Valid is false, inspect the scheme, hostname, and fragment, and check for a parsing error such as an invalid port. If Valid is true, test the actual connection separately.
The tool parses the supplied string with the runtime's WHATWG URL API. Parsing separates the scheme, host, path, query, and fragment and applies the parser's normalization rules. For example, scheme and domain-name casing are normalized. A successful parse supplies structured components for the remaining checks; a parsing failure returns false.
- Parse the address without a base URL. A relative reference such as /chat therefore fails.
- Check the normalized scheme. Only ws:, wss:, http:, and https: are accepted.
- Check that the parsed hostname is non-empty.
- Check the serialized URL for a literal #, which identifies a fragment even when it has no text.
- Return valid = true only when parsing and all three component checks succeed. Otherwise return valid = false.
HTTP and HTTPS addresses are accepted because the browser's WebSocket constructor maps http to ws and https to wss before checking the scheme. Passing https://example.com/chat to that constructor requests a secure WebSocket connection. An ordinary HTTPS server still needs to support the WebSocket handshake. This validator reports a boolean and leaves the supplied address unchanged.3
| Input URL | Valid | Reason |
|---|---|---|
| wss://example.com/chat | true | Supported scheme, host present, and no fragment. |
| ws://example.com/chat?room=blue | true | A query is allowed. |
| https://example.com/chat | true | The constructor maps HTTPS to WSS. |
| http://example.com/chat | true | The constructor maps HTTP to WS. |
| wss://example.com/chat#messages | false | A fragment is present. |
| ws://example.com/# | false | An empty fragment is still a fragment. |
| /chat | false | A relative reference needs a base URL. |
| ftp://example.com/chat | false | The scheme is unsupported. |
| wss://example.com:65536/chat | false | The URL parser rejects an out-of-range port. |
| wss://example.com/chat%23room | true | The encoded %23 belongs to the path; it does not start a fragment. |
Why URL fragments fail the check
The WebSocket constructor forbids any fragment, including an empty one. The tool checks the serialized address for # so ws://example.com/# fails even though its fragment text is empty. A percent-encoded %23 in the path or query represents data and passes this particular check.
Input requirements and the result
- WebSocket URL
- The required URL string. An empty or unparseable string returns false. Extremely large inputs are rejected by input validation.
- Valid
- True when the parsed address meets the scheme, hostname, and fragment checks; false when parsing or a check fails. The result gives no individual failure reason.
In the portable tool contract, a missing URL, a non-string value, an over-length string, or an extra input field produces an input-validation error. This is separate from a correctly supplied string whose URL check returns false.
Limitations of URL validation
- A true result establishes URL syntax and these component checks. DNS resolution, server availability, TLS certificates, authentication, and handshake acceptance are untested.
- The check accepts schemes with and without TLS. Application security rules, browser policies, and network restrictions can still prevent a connection.
- An accepted address may contain a username, password, or query data. The check does not assess whether credentials are appropriate or whether the destination is trusted.
- The validator accepts URL forms that the WHATWG parser can normalize. A true result does not establish that the original spelling follows a stricter application formatting rule.
- Only the endpoint URL is checked. WebSocket subprotocol names, message formats, server capabilities, and connection lifecycle behavior require separate checks.
The browser's WebSocket constructor can resolve a relative URL against its environment's base URL. This tool has no base-URL input, so a reference such as /chat returns false here even when it could work in a particular page. Resolve it against the intended base before checking the resulting absolute address.4
Alternative or Complementary connection checks
Inspect individual URL components when you need to explain a false result or enforce a specific host, scheme, or port policy. After the address passes, test the actual endpoint in the intended application environment and inspect its handshake and connection events. The browser constructor starts a connection attempt immediately, so this operational test contacts the server.
References
-
RFC 6455: The WebSocket Protocol, sections 1.2 and 3 — Internet Engineering Task Force
-
WebSocket: WebSocket() constructor — MDN Web Docs
Similar or alternative tools
- URL Protocol
Inspect the normalized scheme when you need to distinguish ws, wss, http, https, or an unsupported scheme.
- URL Hostname
Inspect the parsed hostname when checking that an endpoint names the intended server.
- URL Hash
Inspect a non-empty fragment that makes validation fail. This helper returns an empty string for both an absent fragment and a bare #, so an empty result does not rule out an empty fragment.
- URL Is Absolute
Check whether an address parses without a base URL. This helper accepts schemes beyond those supported by WebSocket URL Validator.
- URL Port
Inspect the normalized port when reviewing an endpoint configuration. The parser omits an explicit port that matches the scheme's default.