SSML for French text-to-speech: what a tag actually does, measured
SSML promises control over pauses, pronunciation and emphasis. We measured a single pause tag on two versions of our engine: the silence it produced, what it did to the rest of the sentence, and why we don't hand tags to editors.
Sooner or later, anyone trying to make a synthetic voice read better runs into SSML. The Speech Synthesis Markup Language is a W3C standard (1.0 in 2004, 1.1 in 2010) for annotating text before it reaches a speech engine. A 300-millisecond pause, a word to spell out, a string to read as a date, an enforced pronunciation: all of it goes inside angle brackets, in the middle of the sentence.
On paper, it fixes every reading mistake. In practice the useful question is not "what does the standard allow" but "what does the engine do with the tag it is given". We measured that on the simplest tag of all, the pause, in French. The result says a lot about what to expect from the rest.
What the tags promise
A handful do most of the work:
<break>inserts a silence of a given length;<say-as>says how to read something (a date, a number, letters spelled out);<phoneme>gives the exact pronunciation of a word in a phonetic alphabet;<sub>swaps a written word for a spoken one, handy for acronyms;<prosody>and<emphasis>change rate, pitch and stress.
Older rule-based engines built speech piece by piece and applied these tags literally. Modern neural voices work differently. They generate a sentence as a whole, taking everything around each word into account, so a tag becomes a constraint pushed into a process that was not designed around it. Many engines only accept some of the tags, and their documentation does not always say so plainly.
The test: a pause requested, a pause measured
It started with a listening note in August 2026. In the demo sentence on our French home page ("… un 1er janvier : tout est lu comme vous le diriez", roughly "a 1st of January: everything is read the way you'd say it"), the voice ran straight through the colon. We first checked that our own text preparation passed the colon through untouched. It did, so the pause was entirely down to the engine.
We then measured the silence at the colon, from the word-level timestamps the engine returns, with and without a 300 ms break tag, same sentence, same voice.
- August 2026 version: 0.000 s of silence with no tag, 0.640 s with the 300 ms tag;
- September 2026 version: 0.526 s with no tag, 0.532 s with it.
Three lessons came out of it, and none of them was in the documentation.
The number you write is not the silence you hear. In August, 300 ms requested gave 0.64 s of silence. The tag splits generation in two, and the split adds its own gap. An editor who typed "300 ms" expecting 300 ms would be off by a factor of two.
The problem fixed itself. The September version pauses at the colon unprompted, just over half a second. The tag now adds six thousandths of a second.
And the tag damages everything else. With the tag, the whole sentence grows from 5.30 s to 5.94 s. Every word before the colon is shifted, because the engine, cut in two, loses the thread of the sentence and re-paces it. Nobody would have noticed without measuring or listening very closely.
So we removed the tag for that version. Our rule now is simple: a pause is only inserted for an engine version on which it has been measured, and a version that has never been measured gets none.
The risk nobody mentions: the tag read aloud
There is something worse than a useless tag. If an engine stops interpreting a tag one day (a new version, a changed setting), it reads it as text. Listeners then hear something like "less than break time equals three hundred milliseconds" in the middle of an article. No automated check catches that: the file is produced, its duration looks normal, and only a human ear notices.
That is the main reason we don't give SSML to newsrooms and site editors. A tag written into an article in March can turn into a nonsense sentence in September without anyone touching the article.
What replaces it for French articles
What people want from SSML in a news or blog article comes down to three needs. Each one has a lever in WeDispatch that does not depend on the engine version.
Pauses: punctuation. A comma, a full stop and a semicolon do not produce the same silence, and a well-punctuated paragraph breathes better than any tag. We measured the difference in duration between two punctuations of the same paragraph. It is the first tool, and the most stable one.
Dates, numbers and acronyms: text preparation. What <say-as> does by hand, our preparation step does before synthesis, in French: "1er", "15 h 30" and "3,5 %" are rewritten in their spoken form. It is described, limits included, on the French text-to-speech page.
How a word is pronounced: the lexicon. Instead of <phoneme> or <sub>, the pronunciation lexicon takes one line per word, in the form word = pronunciation, written in ordinary spelling rather than a phonetic alphabet. It applies to whole words, respects an initial capital, and runs before every synthesis, including in Faithful reading mode. It is available on paid accounts.
What we don't offer: emphasis and prosody set word by word. Neural voices handle them poorly through tags, and an article is not a script to be performed.
So should you forget SSML?
Not if you are building your own voice application, on an engine whose version you control, with time to re-listen to everything after each update. SSML is a precise tool in that setting. But if you publish articles, the question to ask a provider is not "do you support SSML?". It is "what happens to my tags when your engine changes?" If they have never measured the answer, you will find it out by ear.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo