Text to Speech vs Text to Dialogue WebSockets

This guide shows you how to choose the right WebSocket for streaming speech and how the two protocols differ.

This feature is currently offered as a Beta Service. By enabling access, you agree to the Beta Services Addendum and acknowledge that usage will be billed at $70/1M chars starting on your next billing date, unless otherwise agreed with your account owner.

ElevenLabs exposes two different WebSocket products for streaming synthesized speech. They solve different problems, accept different message shapes, and target different models.

Which WebSocket should I use?

Use the Text to Speech (TTS) WebSocket when you stream plain text for one voice per connection (the voice is fixed in the URL) and you want non-v3 models such as Flash or Multilingual v2, optional SSML, chunk schedules, or the multi-context variant for agent-style interruption handling.

Use the Text to Dialogue (TTD) WebSocket when you need Eleven v3 dialogue behavior: expressive delivery, per-chunk voice_id, turn boundaries (new_turn), and the same dialogue-oriented buffering used for v3 on the server. Access may require workspace enablement in addition to normal Text to Speech permissions.

For batch or HTTP streaming dialogue (full request in one call), use Create dialogue or Stream dialogue instead of a WebSocket.

Comparison

Text to Speech WebSocketText to Dialogue WebSocket
API referenceTTS stream-inputTTD WebSocket
URLwss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/stream-inputwss://api.elevenlabs.io/v1/text-to-dialogue/stream-input
Voice selectionOne voice_id in the path; all streamed text uses that voiceFirst message registers one or more voices by ID; each inputs[] entry names a voice_id
ModelsFlash, Multilingual v2, and other supported TTS models. Not eleven_v3 on this endpoint.model_id must start with eleven_v3 (for example eleven_v3 or eleven_v3_conversational)
First client messageInitialize with a space and optional voice_settings / generation_config (see realtime TTS guide)Must include voices (and credentials if not already sent via headers or query)
Ongoing textSend a text string (typically trailing space); optional flush, try_trigger_generation, etc.Send inputs: { text, voice_id, new_turn? } objects; optional flush, close_socket, keep_alive
Buffering / schedulingChunk length schedule and related TTS WebSocket controlsServer buffers until enough text is present (roughly 40 characters and 8 words) before emitting audio, unless you flush
Multi-speaker on one socketUse multi-context WebSocket for multiple parallel TTS contexts, not multi-speaker dialogue semanticsUp to 10 registered voices for eleven_v3; eleven_v3_conversational allows only one registered voice
InactivityConfigurable inactivity_timeout (TTS WebSocket query)Fixed 20s between client messages unless you send keep_alive
AlignmentOptional sync_alignment (TTS field naming in API reference)Optional sync_alignment; JSON uses snake_case fields on responses (for example is_final, char_start_times_ms)

When the TTS WebSocket is the better fit

  • You already integrate Flash or Multilingual v2 for latency or language coverage.
  • You want one narrator voice per connection and a simple text-per-frame protocol.
  • You need multi-context orchestration for barge-in and parallel utterances (multi-context guide).

See Generate audio in real-time for a full walkthrough of the TTS WebSocket.

When the TTD WebSocket is the better fit

  • You target Eleven v3 dialogue (expressive tags, conversational pacing, multi-speaker lines).
  • You stream scripted or LLM-generated dialogue where the speaking voice can change per line without opening a new connection.
  • You want WebSocket-shaped incremental input with v3-only dialogue generation on the server.

For a hands-on walkthrough, use Realtime Text to Dialogue. Protocol details are in the API reference.