← Blog · 8 November 2026 · Lire en français

Browser text to speech or prepared audio: what your visitors actually hear in French

Every browser can already read a page aloud, for free. So why produce audio at all? Because the browser's voice belongs to the visitor's device, not to you. A thirty second console test to see it for yourself, and why the gap is wider in French than in English.

This is a fair objection, and we hear it often from publishers and site owners: "Browsers already read pages aloud. So does the operating system on my phone. Why pay for audio my visitors already get for free?"

The short answer is that the browser's voice belongs to the visitor, not to you. It differs from one device to the next, you never hear it the way they do, and when it gets something wrong you have no way to fix it. For an English text the gap can be modest. For French, with its liaisons, its number formats and its acronyms, it shows quickly. Here is how to check it yourself rather than taking our word for it.

The thirty second test

Browsers expose their speech engine to web pages through a standard interface called speechSynthesis. Open your browser's developer console (F12, then the Console tab) on any page and paste:

``
speechSynthesis.getVoices().filter(v => v.lang.startsWith("fr")).map(v =>
${v.name} | ${v.lang} | local: ${v.localService})
``

If the list comes back empty, run the same line again a second later; voices load asynchronously. What you get is the set of French voices available on that particular device. Try again on another computer, on a phone, in another browser. The names change, the count changes, and sometimes there is only one.

Then listen to the first one reading a typical French sentence:

``
const u = new SpeechSynthesisUtterance("Les 1 200 abonnés de la CAF ont été reçus le 1er mars à 15 h 30."); u.lang = "fr-FR"; speechSynthesis.speak(u);
``

The sentence packs four classic traps: a number with a space as thousands separator, an acronym that French speakers say as a word, an ordinal written "1er", and a time written "15 h 30". What you hear is what a visitor with your exact setup would hear. Nobody else.

What the test shows

Three things, each checkable with the lines above.

The voice depends on the device. Depending on the system and its version, the French voice on offer ranges from a recent, fairly pleasant one to an old, very mechanical one. Two people on the same page do not hear your text the same way, and you cannot know which one you have.

Some voices do not run on the device. The local column tells you: a voice marked false is not synthesised locally, so the text is sent to a service run by the browser or OS vendor. That is not wrong in itself, but it is a data path you do not control and your visitor is probably unaware of. We documented ours, step by step, in where your text goes when a French TTS reads it.

Nobody prepares the reading. The browser receives the text as written and decides alone. "1er" may come out letter by letter, "15 h 30" as "fifteen h thirty" in French, and the acronym is either spelled or pronounced depending on the voice. Nobody has listened, and nobody can correct it. The only lever a site owner has is rewriting the text for the ear of a voice they have never heard.

What prepared audio does differently

Audio produced for an article is a file, the same file for everyone. It sounds less impressive than a technology, but everything else follows from it.

  • You hear what your visitors hear. There is one reading, and you can play it before publishing. If it is wrong, it is wrong for you too, and you know.
  • The text is prepared before it is read. Leftover HTML entities, dividers and other marks written for the eye go through a cleanup step before the voice, detailed in what should not be read aloud. For the rest, such as a sidebar or a "read also" block, you can choose exactly which text the voice reads. A browser reads whatever it finds, navigation included when there is no reader mode.
  • A mistake gets fixed once. A name read wrongly, an acronym spelled when it should be spoken: one line in the pronunciation lexicon, applied to whole words before every synthesis, and the error does not come back on later articles. With the browser's voice, the same error replays on every visit, on every affected device, and you never hear it.
  • The voice is chosen, and it stays. You pick it for your editorial tone, and a regular listener hears the same voice from one article to the next. How we select and test French voices is explained on our French text to speech page.

The file also lives outside the page: as a podcast episode, as a download for offline listening, with chapters and subtitles. The browser's voice only exists inside the open tab.

What the browser voice does well

Stopping there would be unfair. Browser speech has real strengths:

  • It costs nothing, to you or to the visitor.
  • It reads everything, including what you never turned into audio: comments, old pages, documents.
  • It is set by the user, for the user. Someone who relies on it daily has often picked their voice and speed, and knows them better than any voice you could impose.

That last point matters most for blind and low vision users. They use a screen reader, which is a navigation tool and not just a reading tool, and an audio version does not replace it. Both coexist, and we explained why in audio version versus screen reader.

The real question

So the choice is not "audio or browser". The browser will stay, and that is fine. The question is: who is responsible for how your text sounds?

With the browser's voice, nobody. The text goes out, each device reads it its own way, and you never find out. With prepared audio, you are: you listen, you correct, and what you approved is what everyone hears. For a site where the text is the product (a newsroom, a local authority, a professional firm), that responsibility is what you are paying for, more than any particular voice.

To compare seriously, run the console test with one of your own paragraphs, then put the same paragraph through our ten minute voice test. You will have an answer based on your text, not ours.

Give your articles a voice with WeDispatch

This blog is itself voiced by WeDispatch. Curious how it sounds on your content?

Book a demo

Read next