IndexTTS Online Guides
TTS Punctuation and Pause Formatting Guide
Practical guidance for using commas, periods, line breaks, dashes, colons, and sentence length to make synthetic speech easier to control and test.
Punctuation in a text-to-speech script is part of the generation input, not just decoration. It helps a speech model infer where one thought ends, where another begins, and how phrases should be grouped. The practical mistake is to treat punctuation like a hidden timing language. A comma does not guarantee an exact pause, and two models can interpret the same sentence differently.
The more reliable workflow is to write clear spoken text first, then test the smallest possible formatting change when the delivery sounds wrong.
Start with normal sentence structure
Use punctuation the way a careful human editor would. Periods should close complete thoughts, commas should mark natural groups, question marks should identify questions, and colons should introduce an explanation or list.
For example:
The update is ready. Before you publish it, review the pricing page, the help center, and the final call to action.
This is usually a better starting point than inserting repeated commas, ellipses, or unusual symbols simply to force pauses. If the script is confusing to a human reader, it becomes difficult to know whether a bad result came from the model or from the text itself.
Periods are the clearest boundary
Long sentences often sound rushed because the model tries to preserve one continuous prosodic contour. If two clauses can stand on their own, split them.
Instead of:
We finished the first version and the team reviewed it and we changed the introduction and now we are ready to publish.
Try:
We finished the first version. The team reviewed it and changed the introduction. Now we are ready to publish.
The second version gives the model clearer boundaries and gives you smaller units to regenerate when one part sounds wrong.
Use commas for grouping, not as a pause button
A comma works best when it matches the real grammar of the sentence.
After the meeting, send the revised file to Alex.
The comma separates an introductory phrase. Compare that with:
After the meeting, send, the revised file, to Alex.
The second version may create unnatural phrasing because the punctuation conflicts with the sentence structure.
If you need a stronger break than a comma provides, first ask whether the text should simply become two sentences.
Line breaks help production even when the acoustic effect varies
One spoken sentence per line is a useful format for voiceover work:
Welcome back to the channel.
Today we are comparing two different reference recordings.
Listen for clarity, pacing, and speaker consistency.
This makes the script easier to review, align with subtitles, and regenerate in chunks. Do not assume every model will create the same pause at every line break. Treat line breaks as a production-organization tool first and an acoustic hint second.
Colons can improve setup-and-explanation delivery
Colons are useful when the first phrase prepares the listener for what comes next.
The rule is simple: keep the reference clean.
Check three things: pronunciation, pacing, and artifacts.
This structure often works well in tutorials and product walkthroughs because the first phrase creates context and the second completes the idea. Avoid using many colons in one paragraph when periods would be clearer.
Dashes are expressive but should be tested
An em dash can signal contrast or an aside.
The first take was usable — but the second was cleaner.
Different speech systems may interpret dashes differently. Some create a noticeable pause and some barely react. If the dash communicates real meaning, keep it. If it was inserted only to force timing, compare it against a comma and a period.
Ellipses are easy to overuse
Ellipses can imply hesitation or trailing speech:
I thought the file was here...
That can be useful for dialogue, but repeated ellipses can make ordinary narration sound slow or theatrical. They are a poor substitute for deliberate sentence design. Use them only when hesitation is actually part of the intended delivery.
Write lists for listening rather than visual scanning
A written list can be dense because the reader sees all the items at once. Audio listeners do not.
Instead of:
The problems are noise, echo, clipping, multiple speakers, inconsistent distance, background music, and poor pronunciation.
Try:
Start with the recording. Check for noise, echo, and clipping. Then check the speaker. There should be one voice, at a consistent distance, with no background music.
The second version groups information into chunks the listener can process in sequence.
Check numbers and abbreviations before blaming punctuation
A sentence can sound awkward because a model is interpreting a number, acronym, version string, or product name unexpectedly. More commas will not solve that problem.
If the sentence includes text such as 2026, 3–30 seconds, API, a domain name, or a product version, test the difficult term itself. Writing a value in the form you want spoken can be more reliable than adding punctuation around it.
For example, a script intended to say “three to thirty seconds” may be easier to control when that phrase is written in words.
Keep sentence length under control
Sentence length is one of the most effective pacing controls. A sentence containing several ideas, multiple numbers, a parenthetical clause, and a long list asks the model to infer too much structure at once.
A useful editing pass is:
- identify the main idea of each sentence;
- split sentences containing unrelated ideas;
- move secondary details into a following sentence;
- regenerate before adding more punctuation.
This improves human readability and synthetic speech at the same time.
Use a controlled pause test
When one sentence sounds wrong, build a tiny test set instead of rewriting the whole script.
Version A:
The update is ready, but we should review it first.
Version B:
The update is ready. But we should review it first.
Version C:
The update is ready — but we should review it first.
Keep the model, reference voice, language, emotion, and pace unchanged. Generate each version and listen for the specific effect you care about.
Ask concrete questions:
- Is the pause too short or too long?
- Does the second clause restart too strongly?
- Does the speaker lose energy after the boundary?
- Does one version introduce an artifact?
That turns a vague impression into a reusable production decision.
Change one variable at a time
If you change punctuation, emotion, pace, reference audio, and model together, you cannot identify what caused the improvement.
For a useful A/B test, change one factor. On IndexTTS Online, Voice Lab can be used to keep the reference and target text controlled when comparing IndexTTS2 and IndexTTS 2.5, or to keep the model fixed while you test script formatting.
Production checklist for pauses
Before generating a final voiceover, review the script in this order:
- Make each sentence understandable on its own.
- Split sentences carrying too many ideas.
- Use normal periods, commas, question marks, and colons.
- Write lists for listening rather than visual scanning.
- Check numbers, abbreviations, and names before blaming punctuation.
- Use dashes and ellipses only when they express real meaning.
- A/B test one punctuation change when delivery is still wrong.
- Regenerate only the affected chunk in long-form work.
The important principle is simple: punctuation should clarify structure. It should not become a collection of hidden control codes. A clean script gives the model fewer ambiguous decisions to make, and controlled testing tells you much more than adding random symbols until one take happens to sound acceptable.