Text Normalization - Cartesia Docs

Text normalization converts written forms into spoken forms: 7:00 PM is spoken as “seven PM”, and (415) 555-1212 is read as a phone number rather than a twelve-digit string. It runs automatically on every TTS request before the model speaks. You control it with the normalization field:

auto (default) — Cartesia decides how dates, times, and numbers are read
off — skip the normalizer
a locale code such as en-IN — read dates and numbers the Indian English way. See supported locales.

Most transcripts need no preparation. This page covers what the normalizer handles, current limitations and their workarounds, and how to turn it off.

What gets normalized

Category	Example input	Status
Dates	`04/20/2026`	Common written forms are automatically normalized
Times	`7:00 PM`, `14:30`	Common written forms are automatically normalized. 24-hour times are read as-is in the language’s convention (e.g. “fourteen thirty”)
Phone numbers	`(415) 555-1212`	Common written forms are automatically normalized
Currency	`$19.99`	Common written forms are automatically normalized
Units	`km`	Units with everyday usage are automatically normalized
Numbers	`1,234,567`	Common written forms are automatically normalized
Date ranges	`1999-2000`	Not normalized — write the range with “to”
Fractions	`2/3`	Not normalized — write them out (“two thirds”)
Other	Equations, chemical compounds, uncommon units (e.g. V, Pa)	Not normalized — write them out (“volts, pascals”)

Normalized categories are locale-aware and read according to the conventions of the request’s language. Common written forms read correctly in the formats shown on prompting tips; for unusual forms, pre-normalize as a fallback.

Known limitations

A date or year range reads out wrong

Hyphenated ranges like 1999-2000 or Dec 5-Dec 12 are not automatically normalized in any language. Write the range with “to” instead:

Unreliable	Reliable
`The war lasted from 1999-2000.`	`The war lasted from 1999 to 2000.`
`Open Dec 5-Dec 12.`	`Open Dec 5 to Dec 12.`
`$10-15`	`10 to 15 dollars`

Industry-specific Terms

Some industries may have common abbreviations that are mutually understandable within that group (PAX = passengers for airlines). Because these abbreviations are not generally used, we recommend pre-normalizing these terms to ensure that they are spoken as expected.

Abbreviations

Common patterns (Dr. Smith, 123 Main St) generally read correctly. Less common titles, abbreviations, and address formats may not (e.g. STE) — write the specific form out as it should be spoken, or use a pronunciation dictionary for a recurring term.

Turning normalization off

See turning normalization off in Advanced capabilities.

Troubleshooting a read-out problem

Right words, wrong sounds? Use a pronunciation dictionary.
A written form expands into the wrong words? Rewrite the input in a form the normalizer handles or pre-normalize the transcript.
Still wrong? Pre-normalize the transcript and turn normalization off. This gives you full control of the spoken form.

For transcript-writing guidance, see prompting tips.

Normalizer worked examples

Pre-normalized text with the normalizer off

For “teleprompter” transcripts you’ve already written out the way they should be spoken, custom symbol read-outs, or all-caps words that should be spoken as words:

{
  "model_id": "sonic-3.6",
  "transcript": "Your total is nineteen dollars and ninety-nine cents.",
  "voice": "a0e99841-438c-4a64-b679-ae501e7d6091",
  "locale": "en",
  "normalization": "off",
  "output_format": { "container": "mp3", "sample_rate": 44100, "bit_rate": 128000 }
}

Only the automatic normalizer is skipped — see turning normalization off for exactly what still applies.

British accent with US reading conventions

Pick the accent with the voice, pick the reading conventions with normalization. This example uses Gemma, a British-accented voice.

{
  "model_id": "sonic-3.6",
  "transcript": "Your appointment is on 03/04/2026.",
  "voice": "62ae83ad-4f6a-430b-af41-a9bede9286ca",
  "locale": "en-GB",
  "normalization": "en-US",
  "output_format": { "container": "mp3", "sample_rate": 44100, "bit_rate": 128000 }
}

This reads with a British accent and US conventions (03/04/2026 as March fourth).

Different read-out conventions inside one transcript

If one clause needs Hindi read-outs and another needs English read-outs, split the transcript and send two requests with different normalization values and the same voice, so the accent stays consistent, then concatenate the audio on the client side:

Request 1

{
  "model_id": "sonic-3.6",
  "transcript": "Aapki appointment 15 tareekh ko hai.",
  "voice": "a0e99841-438c-4a64-b679-ae501e7d6091",
  "locale": "hi-IN",
  "normalization": "hi-IN",
  "output_format": { "container": "raw", "encoding": "pcm_s16le", "sample_rate": 44100 }
}

Request 2

{
  "model_id": "sonic-3.6",
  "transcript": "Please arrive by 2:30 PM on 08/15/2026.",
  "voice": "a0e99841-438c-4a64-b679-ae501e7d6091",
  "locale": "hi-IN",
  "normalization": "en-IN",
  "output_format": { "container": "raw", "encoding": "pcm_s16le", "sample_rate": 44100 }
}

On the WebSocket API, raw PCM chunks from consecutive generations can be concatenated directly.

​What gets normalized

​Known limitations

​A date or year range reads out wrong

​Industry-specific Terms

​Abbreviations

​Turning normalization off

​Troubleshooting a read-out problem

​Normalizer worked examples

​Pre-normalized text with the normalizer off

​British accent with US reading conventions

​Different read-out conventions inside one transcript