The browser coordinates speech playback
When a page asks to speak some text, it hands that text to speechSynthesis, a browser interface defined by the Web Speech API. The browser doesn't generate the audio itself; it passes the text down to whichever text-to-speech engine your operating system already has installed, gets audio back, and plays it through your speakers. Nothing about that round trip involves a network request. The text never has to leave your device for the speech to happen, which is exactly why a tool like this can make an honest "nothing uploaded" claim.
Available voices depend on the environment
speechSynthesis.getVoices() exposes the voices available to that browser session. The list can load asynchronously and varies by installed language packs, operating system, browser and user settings. A webpage can select from reported voices, but it cannot guarantee that the same name or quality exists elsewhere.
Why standard playback does not produce an MP3
This isn't a missing feature Orisod chose to leave out; the Web Speech API simply never defined a way to capture its output as a file. It has one job: turn text into sound and play it, live, through the device's audio output. There's no encoding step, no buffer handed back to the page, nothing a script could redirect into a downloadable .mp3 or .wav. Any tool that tells you otherwise is either running actual server-side speech synthesis (which usually means your text left your device) or using browser-specific recording workarounds that don't work reliably across devices. Being upfront about that limitation up front is more useful than quietly overpromising and letting people find out the hard way.
Long passages need careful queueing
Long utterances can stop, stall or behave inconsistently in some browser and platform combinations. Splitting text into manageable segments and queueing them improves resilience and enables sentence highlighting. Sentence segmentation is itself language-dependent, so abbreviations and unusual punctuation still need care.
Playback behavior to expect
Closing or navigating away from the initiating page commonly stops playback, but lifecycle behavior can differ across browsers and background states.
Additional system voices may improve the options when the operating system supports installation. A webpage cannot add a native voice through the Web Speech API alone.
Pause, resume, boundary events and highlighting vary across engines. These platform differences can limit synchronization even when the page code is correct.
Try text-to-speech in your browser
Orisodโs Read Aloud tool uses voices reported by your browser and offers speed, pitch and sentence highlighting. Voice availability, networking and playback behavior depend on your browser, operating system and selected voice.
Read text aloud โBrowser speech synthesis is best understood as a request for live playback through the current platform. Test the selected voice and controls on the device that will actually be used, and verify privacy assumptions for that voice rather than relying on a universal โlocalโ claim.