Text to Speech Text Reader: Pricing and Code (2026)

A text to speech text reader is any tool that takes written text and plays it back aloud in a synthetic voice. The phrase covers three quite different products: a free web box where you paste a paragraph and press play, a phone app that reads e-books while you commute, and an API you call from your own software to produce audio files you keep. This article explains how all three work, what the free ones can and cannot do, and how to build the third kind yourself with code you can copy today.

What is a text to speech text reader?

Text-to-speech, usually shortened to TTS, is the conversion of written language into audible speech by software. Early systems stitched together recorded fragments of human speech; modern ones use neural networks that predict an audio waveform directly from text, which is why they can produce believable pauses, emphasis and breathing. The history of speech synthesis goes back decades, and the jump in quality over the last few years is the reason a text to speech text reader is now pleasant to listen to for an hour rather than merely intelligible.

Three terms get mixed up constantly, so it is worth separating them:

• Text reader (or TTS reader): you give it a block of text, a document or a URL, and it reads that content aloud. This is what people mean by a text to speech text reader.
• Screen reader: accessibility software that narrates the entire interface, including menus, buttons and form labels, for blind and low-vision users. NVDA, JAWS and VoiceOver are screen readers. The University of Illinois disability resources guide is a good primer on how these tools are used in practice by students.
• Speech-to-text: the opposite direction. Automatic speech recognition turns your voice into written words, which is what the microphone key on your phone keyboard does. If you came here looking for dictation, that is the technology you want, not TTS.

Mechanically, every text to speech text reader does the same four things: it extracts clean text from whatever you gave it, splits that text into manageable pieces, sends each piece to a voice engine, and plays the resulting audio in order. The differences between products are in where the voice engine runs and whether you are allowed to keep the output.

Free text to speech text reader options, and where they stop

You already own a text to speech text reader. Windows ships Narrator and a set of system voices, macOS and iOS have VoiceOver and Spoken Content, and Android includes Google’s Speech Recognition & Synthesis engine that any app can call. Browsers expose those same voices to JavaScript through the Web Speech API, which means a free online reader can work entirely on your machine with no server involved:

// Runs in the browser, uses the voices installed on the device
const utterance = new SpeechSynthesisUtterance(
  "Paste any text here and the browser will read it aloud."
);
utterance.rate = 1.1;            // 0.1 to 10, 1 is normal
utterance.voice = speechSynthesis
  .getVoices()
  .find(v => v.lang.startsWith("en"));
speechSynthesis.speak(utterance);

That snippet is genuinely useful. It costs nothing, needs no sign-up, and the text never leaves the device, which is why several of the free “no sign up” readers on the web are thin wrappers around it. Use it for proofreading your own writing, for listening to an article while you wash up, or for a quick accessibility fallback in an app.

It stops being enough at four specific points:

1. You cannot save the audio. The browser plays the speech, it does not hand you an MP3. Anything you want to publish, attach to a video or ship in a podcast feed needs a file.
2. The voice is not yours to choose. Available voices depend on the operating system, the browser and what the user has installed. The same page sounds different on every machine, and some installs have only one flat voice.
3. Quality tops out below current neural models. System voices have improved, but for narration people will listen to for an hour, the gap is obvious within a sentence.
4. Daily caps on hosted free tools. Web readers that use their own servers almost all limit characters per day, lock downloads behind a plan, or watermark the audio. That is fine for a paragraph and useless for a 300-page document.

So the honest answer to “what is the best free text to speech text reader” is: the one already on your device, for listening. The moment you need a file, a consistent voice or commercial rights, you are buying synthesis by the character.

Which models to use for a text to speech text reader

On Unicorn API, audio generation runs through one endpoint and one key, and you pay in credits. Three models matter for a text to speech text reader, and they split cleanly by job:

Model	Best for	Price
Elevenlabs Text to Speech Turbo V2.5	Bulk reading: articles, documents, whole books, anything where volume matters more than nuance	6 credits per 1,000 characters
Elevenlabs Text to Speech Multilingual V2	Published narration and non-English text where prosody and accent quality are worth double the price	12 credits per 1,000 characters
Elevenlabs Text to Dialogue V3	Multi-speaker passages: interviews, scripts, dialogue-heavy fiction with a voice per character	14 credits per request

Both TTS models take the same input fields, so switching between them is a one-word change: text, voice, speed, style, stability, similarity_boost, language_code, timestamps, plus previous_text and next_text for context. That shared shape is the practical reason to prototype on Turbo and promote the chapters that matter to Multilingual V2 later, rather than committing to one model up front. The full list of audio and other models lives in the model catalog.

Pricing detail that changes how you write your code: both TTS models bill per request, multiplied by ceil(length of text / 1000). A 1,200-character request is billed as two units. A 100-character request is billed as one. Send a paragraph at a time and you will pay several times over for the same book.

How to build a text to speech text reader (with code)

Media generation is asynchronous: you create a job, then poll it until it finishes. Create a key at /keys, export it as UNICORN_API_KEY, and the smallest possible request looks like this:

curl -X POST https://api.unicornapi.net/v1/jobs \
  -H "Authorization: Bearer $UNICORN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "elevenlabs-text-to-speech-turbo-2-5",
    "input": {
      "text": "A text to speech text reader turns written words into audio you can keep."
    }
  }'

The response carries a job id. Poll it until the status is succeeded, then read the audio URL:

curl https://api.unicornapi.net/v1/jobs/JOB_ID \
  -H "Authorization: Bearer $UNICORN_API_KEY"

# { "id": "JOB_ID", "status": "succeeded",
#   "outputs": [ { "url": "https://..." } ] }

Now the real thing. A working text to speech text reader has to chunk text at sentence boundaries just under 1,000 characters, so each request fills exactly one billing unit and no sentence is cut in half mid-clause:

import os, re, time, requests

BASE = "https://api.unicornapi.net"
HEADERS = {
    "Authorization": f"Bearer {os.environ['UNICORN_API_KEY']}",
    "Content-Type": "application/json",
}
MODEL = "elevenlabs-text-to-speech-turbo-2-5"
VOICE = "EkK5I93UQWFDigLMpZcX"

def chunk(text, limit=1000):
    """Group whole sentences into pieces of at most `limit` characters."""
    chunks, current = [], ""
    for sentence in re.split(r"(?<=[.!?])\s+", text.strip()):
        while len(sentence) > limit:          # one very long sentence
            chunks.append(sentence[:limit])
            sentence = sentence[limit:]
        if len(current) + len(sentence) + 1 > limit:
            if current:
                chunks.append(current)
            current = sentence
        else:
            current = (current + " " + sentence).strip()
    if current:
        chunks.append(current)
    return chunks

def speak(text, previous=None, following=None):
    body = {"model": MODEL, "input": {"text": text, "voice": VOICE}}
    if previous:
        body["input"]["previous_text"] = previous[-300:]
    if following:
        body["input"]["next_text"] = following[:300]

    job = requests.post(f"{BASE}/v1/jobs", headers=HEADERS, json=body).json()
    job_id = job["id"]

    while True:
        job = requests.get(f"{BASE}/v1/jobs/{job_id}", headers=HEADERS).json()
        if job["status"] == "succeeded":
            return job["outputs"][0]["url"]
        if job["status"] == "failed":
            raise RuntimeError(f"job {job_id} failed: {job}")
        time.sleep(2)

text = open("chapter.txt").read()
pieces = chunk(text)

urls = []
for i, piece in enumerate(pieces):
    urls.append(speak(
        piece,
        previous=pieces[i - 1] if i else None,
        following=pieces[i + 1] if i + 1 < len(pieces) else None,
    ))

for url in urls:
    print(url)

Two things in there are worth calling out. previous_text and next_text give the model the surrounding context so the intonation at a chunk boundary matches what came before, which removes the “every paragraph starts fresh” effect that makes stitched narration sound wrong. And the loop is sequential for clarity: in production, submit all the jobs first, then poll them together, so a long document is not bottlenecked by one request at a time.

To know the cost before spending anything, send the same body to POST /v1/models/price and you get the exact price of that request back:

curl -X POST https://api.unicornapi.net/v1/models/price \
  -H "Authorization: Bearer $UNICORN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "elevenlabs-text-to-speech-multilingual-v2",
    "input": { "text": "...the full text of the chunk...",
               "voice": "EkK5I93UQWFDigLMpZcX" }
  }'

Run that over every chunk of a book before you start and you have an exact budget rather than an estimate. Endpoint details and response fields are in the API documentation, and you can try the same models without writing any code in the audio playground.

Voice settings: speed, stability and pronunciation

Defaults are decent; the four settings below are where a text to speech text reader goes from acceptable to good.

• voice: the voice id. Pick one and hard-code it, because a voice change halfway through a document is the most jarring error you can ship.
• speed: playback pace. Audiobook listeners often want faster than natural; instructional content usually wants slower.
• stability: how much the delivery varies between runs. Higher is steadier and more neutral, lower is more expressive and less predictable. Long-form reading benefits from higher stability, character dialogue from lower.
• style and similarity_boost: how strongly the output pushes toward expressive delivery and toward the reference voice’s timbre. Both reward small adjustments and punish large ones.
• language_code: set it explicitly for non-English text instead of letting the model infer from the characters. Mixed-language passages are the classic source of a French sentence read with an English accent.
• timestamps: ask for timing data and you can highlight each sentence as it plays, which is the feature that makes a reader genuinely useful for dyslexic and ESL readers rather than just convenient.

Pronunciation is the one problem these settings do not solve. Names, acronyms, drug names, chemical formulas and numbers with units all get guessed. Traditional engines accept SSML, an XML markup language for controlling speech output, where you can specify a phonetic spelling for a word. Neural models like these take plain text, so the practical fix is to pre-process: keep a dictionary of your problem terms and rewrite them phonetically in the text you send. “SQL” becomes “sequel” or “ess cue el” depending on which camp you are in. Write once, apply to every job.

What does a text to speech text reader cost?

Credits on a monthly plan cost $0.01 each (Starter $25, Creator $50, Studio $100, Pro $200). Top-up credits cost $0.015 each and never expire, so they are the right tool for an occasional big job rather than steady throughput. See /pricing for the plans. Character counts below assume text chunked to fill whole 1,000-character units:

What you are reading	Characters	Turbo V2.5	Multilingual V2
One page of a document	2,000	12 credits ($0.12)	24 credits ($0.24)
A blog post	6,000	36 credits ($0.36)	72 credits ($0.72)
A long report	50,000	300 credits ($3.00)	600 credits ($6.00)
A full-length novel	400,000	2,400 credits ($24)	4,800 credits ($48)

Dollar figures use the $0.01 monthly-plan credit price. Read in the other direction, a $25 Starter plan is 2,500 credits, which is roughly 400,000 characters of Turbo narration a month: an entire novel, or about 70 blog posts, or a page a day for years.

The number that matters for a product is cost per user per month, and the lever is caching, not model choice. A text to speech text reader that re-synthesises the same help article for every visitor pays every time. Hash the chunk text plus the voice settings, store the resulting audio URL, and serve the cached file on every later request. Most reader apps have a long tail of content that is read once and a short head that is read constantly; caching the head is usually the difference between a few dollars a month and a few hundred.

Multi-voice reading with text to dialogue

Single-voice narration flattens conversation. A novel chapter where three characters argue, or an interview transcript, reads better with a voice per speaker. That is what Elevenlabs Text to Dialogue V3 is for: instead of one text field you send an array of lines, each with its own voice.

curl -X POST https://api.unicornapi.net/v1/jobs \
  -H "Authorization: Bearer $UNICORN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "elevenlabs-text-to-dialogue-v3",
    "input": {
      "dialogue": [
        { "text": "Did the reader finish the whole chapter?",
          "voice": "EkK5I93UQWFDigLMpZcX" },
        { "text": "Every paragraph, in one pass.",
          "voice": "EkK5I93UQWFDigLMpZcX" }
      ],
      "stability": 0.5
    }
  }'

Dialogue V3 is priced at 14 credits per request rather than per character, so the billing logic is the inverse of the TTS models: group as much of a scene as you can into a single call instead of one call per line. The parsing work is yours. Detecting speakers in prose means matching quoted spans and attribution phrases, which is reliable in a screenplay and messy in literary fiction, so it is worth keeping single-voice Turbo as the fallback whenever speaker detection is not confident.

If you are adding background music or sound beds under narration, the same key and the same job endpoint cover Ai Music API Sounds at 3 credits per track and Ai Music API Mashup at 12 credits per track. Our guide to AI music models goes into the music side in detail.

Mistakes people make building a text to speech text reader

• Billing a paragraph at a time. Requests round up to whole 1,000-character units. Sending 40 paragraphs of 250 characters each costs four times what 10 full chunks would. Chunk to fill units, always.
• Feeding raw HTML to the model. Nav menus, cookie banners, image credits and “share this” buttons all get read aloud. Extract article text first, then strip URLs, footnote markers and tables of figures. Bad input is the single biggest cause of a reader that users abandon.
• No context across chunk boundaries. Skip previous_text and next_text and every chunk starts with fresh-paragraph energy, which makes a stitched chapter sound like a sequence of announcements.
• Polling too aggressively. A tight loop with no delay on GET /v1/jobs/{id} buys you nothing. Wait a second or two between checks and submit jobs in parallel instead.
• No cache. Covered above and still the most expensive mistake in production.
• Guessing the price. POST /v1/models/price gives the exact cost of a request before you run it. For a long document, price the whole batch first and you will never be surprised by a bill.
• Ignoring rights. Narrating a book you did not write, or cloning someone’s voice without permission, is a licensing problem rather than a technical one. Check both the content and the voice before you publish.
• Assuming TTS replaces a screen reader. A reader narrates content; a screen reader narrates the interface. If accessibility is the goal, you still need proper semantic HTML, labels and keyboard navigation.

Put together, a working text to speech text reader is about 150 lines of code: text extraction, sentence chunking, a job submit-and-poll loop, a cache keyed on text plus voice, and a player. The synthesis itself is one request. Create a key at /keys, try a paragraph in the playground to pick a voice, and if you work in Cursor or Claude Code you can drive the same models through MCP without leaving the editor.