besttexttospeechapi.com
matchup: ssml-support-compared · run: 2026.10 · fields: verified only

SSML Support Compared: Which TTS APIs Accept Markup in 2026

Google and Amazon Polly publish full SSML references; ElevenLabs, Cartesia, OpenAI, and WellSaid use request settings instead. A practical comparison for teams porting a markup pipeline.

Verdict first

If your pipeline already emits SSML, Google Cloud Text-to-Speech and Amazon Polly are the only two APIs in this run that accept it with a published tag reference. If you are starting fresh and want a structured control layer, ElevenLabs and Cartesia expose request-level style or emotion settings that are easier to validate than markup. OpenAI offers free-text instructions, and WellSaid uses its own tempo, loudness, and pitch tags. The remaining four publish no control layer beyond plain text.

The comparison

The table records what each vendor documents publicly. “No SSML” does not mean “no control”; it means the control is not SSML.

API Markup layer Structured control Source
Google Cloud TTS full SSML reference five named styles plus prosody SSML reference
Amazon Polly SSML tag table by engine newscaster domain, prosody tag table
ElevenLabs no SSML style, stability, speed API reference
Cartesia no SSML emotion, speed, volume API reference
OpenAI no SSML free-text instructions TTS guide
WellSaid proprietary tags tempo, loudness, pitch API page
Deepgram no SSML output encoding and container TTS guide
Typecast no SSML emotion, pitch, intensity, dynamics product page
Uberduck no SSML none documented docs
Respeecher no SSML voice styles described, no parameter list product page

What SSML actually buys

SSML is a W3C markup for controlling synthesis. In practice, four tags do most of the work. A break tag inserts a pause without splitting the request. A say-as tag tells the engine to read a number, date, or currency a specific way. A prosody tag changes rate, pitch, or volume around a sentence. A phoneme or substitution tag fixes a name the model would otherwise mispronounce.

The value is portability. A script with <break time="300ms"/> can move from Google to Polly with a predictable change, because both implement the same tag family. A script that relies on a vendor’s style parameter cannot move without a rewrite. For a product that may change vendors, that is a real cost.

The value is also auditability. Markup lives in the text, so a reviewer can see exactly where a pause or emphasis was requested. A request-level style value is metadata; it can be logged, but it is not visible in the script.

Google: the deepest reference

Google’s SSML page is a tutorial and a reference in one. It documents the supported subset, shows example markup for each tag, and lists the voice families that support each one (reference). It also documents five named styles — apologetic, calm, empathetic, firm, and lively — via a google:style tag, and it notes that only certain voices can speak them.

That last detail is the useful part. A style tag is not a global switch; it depends on the voice. Google’s page names the voices that support the styles, so you can check before you ship. Most vendors document the tag and leave the voice compatibility to a support ticket.

The trade-off is complexity. SSML has reserved characters, nesting rules, and per-voice limitations. A malformed tag can produce silence or an error. If your team does not want to own that, a structured parameter is simpler.

Polly: availability by engine

Polly’s SSML table is the most operationally useful document in this comparison. It lists every supported tag and marks availability for Standard, Neural, Long-Form, and Generative voices (table). It states, for example, that <emphasis> is not available on Neural voices and that <prosody> is partial on Neural. It also warns that unsupported tags produce an error rather than being ignored.

That is exactly the information a migration needs. If your script uses emphasis on a Neural voice, Polly will fail; you need to switch voices or remove the tag. A generic “SSML supported” banner would not tell you that.

Polly also offers a newscaster domain for select neural voices, which is a style control that lives inside the SSML layer rather than beside it. It is narrower than Google’s five styles, but it is documented with the same per-engine precision.

The non-SSML vendors

ElevenLabs exposes voice settings per request: style, stability, similarity boost, and speed. These are numeric or bounded values, so they are easy to validate and easy to log. The trade-off is that they are ElevenLabs-specific; the same script on another vendor needs a different control layer.

Cartesia exposes a generation config with volume, speed, and an emotion enum. The enum is a closed list, which makes it predictable. OpenAI exposes free-text instructions — “speak in a cheerful tone” — which is flexible but harder to test, because the same instruction can produce different results across runs.

WellSaid uses its own tags: tempo, loudness, and pitch. They look like SSML but are not the W3C tags, so a migration needs a mapping. Deepgram documents output format controls but no style layer. Typecast exposes emotion, pitch, intensity, and dynamics through its API. Uberduck and Respeecher publish no control parameter list in the material reviewed.

Who should care

Teams with an existing SSML pipeline should shortlist Google and Polly first. The migration cost is lower, and the per-voice availability tables reduce the risk of a tag failing in production.

Teams starting from scratch should consider whether they need markup at all. A structured style or emotion parameter is easier to validate, and most products need only a handful of presets. If the answer is “we need per-word pauses and pronunciation fixes”, SSML is still the better tool.

Teams that expect to switch vendors should keep the control layer behind an adapter. Whether the adapter emits SSML or a JSON config, the important thing is that the script does not depend on one vendor’s syntax.

The takeaway

SSML is not a checkbox; it is a portability decision. Google and Polly support it deeply, with the voice-level caveats that make it usable. The API-first vendors offer narrower but cleaner controls. Pick the layer that matches your team’s tolerance for markup, and keep the migration path in mind before you write the first tag.

FAQ

Which TTS APIs support SSML?

Google Cloud Text-to-Speech and Amazon Polly publish full SSML references with tag-level availability notes. ElevenLabs, Cartesia, OpenAI, and WellSaid expose request settings or proprietary markup instead of SSML. Deepgram, Typecast, Uberduck, and Respeecher publish no SSML layer in the documentation reviewed.

Can I send SSML to ElevenLabs or OpenAI?

Neither reference documents an SSML input field. ElevenLabs exposes style, stability, and speed settings; OpenAI exposes free-text instructions for tone and delivery. Sending SSML tags as text is not the same as SSML support, and this site does not treat it as such.

Is SSML still worth using in 2026?

It is worth using when you need pauses, pronunciation control, or per-word emphasis that must survive a vendor migration. It is less useful when a vendor native style or emotion parameter gives you the same result with less markup. The trade-off is portability versus control.

What is the closest alternative to SSML on a non-SSML API?

A structured request setting: a style or emotion enum, a speed value, a stability value, or a pronunciation dictionary. These are easier to validate than markup, but they are vendor-specific, so a migration means rewriting the control layer.

↑