Does ChatGPT use SSE or WebSockets?
ChatGPT streams its text responses using Server-Sent Events (SSE), not WebSockets. When you send a prompt, the client opens a single HTTP connection and the server pushes tokens back as a text/event-stream response, one chunk at a time, until the answer is complete. WebSockets are not involved in that flow.
Why SSE fits ChatGPT's token streaming
The reason comes down to the shape of the traffic. Generating a response is a one-way problem: the model produces tokens and the client only needs to display them as they arrive. The client does not send anything back mid-response. That is exactly the case SSE was designed for, a long-lived HTTP connection that carries a stream of events from server to client.
Using plain HTTP also means the stream travels over the same infrastructure as every other request. Load balancers, reverse proxies, CDNs, and corporate firewalls already handle HTTP without special configuration, whereas WebSocket connections often need proxy rules and connection upgrades that break in restrictive networks. SSE also reconnects automatically and lets the server resume from a known event ID, which is helpful for a stream that can run for many seconds.
If you want the broader tradeoffs between the two, we cover them in WebSocket vs SSE.
How the token stream works
The mechanism is visible in the OpenAI API. Set stream: true on a chat completion request and the response arrives as a series of data: lines, each carrying a small JSON chunk with the next piece of the message. A final data: [DONE] line signals that the stream is finished and the connection closes.
On the browser side this is the same pattern as the native EventSource API, though ChatGPT's own web client reads the stream through fetch so it can send the authorization headers and the POST body that EventSource does not support. Either way the transport underneath is an HTTP response with a Content-Type of text/event-stream, which is the defining trait of SSE.
Where ChatGPT does use WebSockets
SSE covers text streaming, but it is not the whole picture. OpenAI's Realtime API, which powers low-latency voice conversations, uses WebSockets (and WebRTC) rather than SSE. Voice is genuinely bidirectional: audio flows from the user to the model and back at the same time, so the full-duplex channel a WebSocket provides earns its extra complexity there.
That split is a useful rule of thumb. One-way server-to-client updates favor SSE, and true two-way exchanges favor WebSockets. For a wider look at how these choices play out against request-response APIs, see WebSocket vs REST API and long polling vs WebSockets.
SSE, WebSockets, and webhooks
SSE and WebSockets both assume a client that stays connected and waits for data, which is the right model for a browser rendering a chat. Server-to-server event delivery is a different problem. When one backend needs to tell another that something happened, holding a connection open is wasteful, and that is where webhooks come in: the sender makes a short HTTP request to the receiver only when there is an event to report.
Many products combine both. A user-facing feature streams tokens over SSE, while the systems behind it exchange events through webhooks. If you are building the outbound side of that, sending events to your own customers with retries and signature verification, Svix provides the webhook infrastructure so you do not have to build it yourself.