"What is the best Arabic text-to-speech?" has no single answer, because the best voice for a Riyadh bank's phone line is not the best voice for a Cairo e-learning course. What you can do is test properly. This is the plan we suggest to teams evaluating Arabic TTS, including when they evaluate us. It takes about an hour and needs nothing more than an API key per vendor and three native speakers.
Step 1: write a test script from your own product
Generic demo sentences hide the problems. Collect 15 to 20 lines from your real use case and make sure they include:
- Numbers in context: prices, dates, times, phone numbers, percentages. "Your balance is 1,250.75 SAR" is where many systems stumble.
- Names: people, places and your own brand, including names that are not Arabic.
- Arabic with English inside it: "Please open the app and tap Settings", the way your customers really talk.
- Your dialect: if you serve the Gulf, write some lines the way a Gulf speaker would say them, not only in formal MSA.
- A long paragraph of 400 to 600 characters, to hear rhythm and breathing.
- Short agent turns: "Sure.", "One moment.", "Is there anything else?". Short lines are where unnatural endings show.
Step 2: generate every line on every candidate
Use each vendor's closest match to the voice you need (gender, age, dialect, register), the same format, and default settings. Save the files with neutral names so listeners don't know which vendor made which file.
Step 3: blind listening with native speakers
Ask at least three native speakers from your target market to rate every clip from 1 to 5 on four questions:
- Pronunciation. Are the words, names and numbers said correctly?
- Dialect. Does it sound like someone from here, or like a foreigner reading Arabic?
- Naturalness. Would you believe a person recorded it?
- Fit. Would you accept this voice for our product?
Average the scores per vendor. Then read the comments: one recurring mistake on your brand name matters more than a small difference in averages.
Step 4: measure what users feel
Quality is half the picture. For anything interactive, measure from your own servers, in your own region:
- Time to first audio with streaming on, over 50 requests. Look at the slow end (p95), not the average.
- Consistency over a session: generate 40 short turns back to back and listen for clicks, volume creeping up, or endings that sound cut off.
- Behaviour under load: run a burst at your expected peak and watch for errors and slowdowns.
Step 5: check the things procurement will ask
- Data residency: where does the audio go? Many GCC buyers need processing in-country.
- Price per character at your real monthly volume, including any premium tier you would actually use.
- Voice cloning and consent: can you create a brand voice, and is speaker consent built into the process?
- Integration: SDKs for your stack, a realtime option for agents, and plugins for the framework you use.
How Hakim approaches this
We built Hakim for exactly this test. Voices are tuned and reviewed by native speakers across Modern Standard Arabic and 15 dialects. Streaming audio starts in about 113 ms p95. Processing stays in-region in the UAE, Saudi Arabia, Qatar or Frankfurt. And there are three tiers, so you can trade latency for expressiveness. The text-to-speech API guide shows how to generate your test set in a few minutes, and the free tier covers a full evaluation.
Run the test, trust your listeners, and pick the voice your customers would choose.