Language Detection API: How Trigram Detection Works
Trigram-frequency language detection identifies the language of a piece of text by counting the three-character sequences it contains and comparing that distribution to precomputed profiles for each language. It is a compact, fast statistical technique that needs no neural model, and it is the approach behind the ipto language detector, which covers 76 languages.
How trigram detection works
Each language has characteristic letter combinations. In English, sequences such as "the", "ing" and "ion" are everywhere; in Spanish, "ión", "que" and "los" take their place; in German, "sch", "ein" and "der" are frequent. A trigram is simply a run of three characters taken from the text, usually after lowercasing and stripping digits and punctuation, with spaces kept so that word boundaries become part of the pattern. The string " th", for instance, signals a word starting with "th".
The detector builds a profile for each language ahead of time by counting trigrams across a large reference corpus and ranking them by frequency. At query time it does the same for your text and measures how close that distribution is to each stored profile. The language with the smallest distance wins, and the gap between the best and the second-best candidate gives you a confidence value. Because the profiles are lookup tables, the work per request is a single pass over the text plus a few comparisons. No remote service is needed, so nothing about the text has to leave the server.
Scripts versus trigrams
Trigram statistics are most useful when many languages share a writing system. Latin, Cyrillic, Arabic and Devanagari scripts each host many languages, and the detector has to rely on frequency patterns to tell Portuguese from Spanish or Russian from Ukrainian. For languages that have a script of their own, such as Greek, Thai, Korean, Tamil or Bengali, the script alone is usually enough to name the language, so no frequency comparison is required. Chinese and Japanese need slightly more care, since Japanese text mixes kana with Han characters, which is a strong cue for Japanese. In ipto, 61 of the 76 languages are separated by trigram frequency and the other 15 are recognized from their script.
Where it works well and where it does not
For short web text such as titles, comments, search queries and support tickets, trigram methods are a good fit. They need very little input to produce a useful guess, they are cheap to run and they are fully deterministic, which makes behaviour easy to test and debug. Large neural classifiers can be more accurate on difficult cases, particularly with extremely short or noisy text, but they cost more to run and are harder to inspect. Which is better depends on your accuracy needs and your constraints; for routing and tagging, a lightweight detector is frequently enough.
Know its failure modes before relying on it:
- Very short input. A handful of characters offers too few trigrams. The ipto API returns a null language for input shorter than 10 characters, and for input under roughly 30 characters it may give a best guess but marks
reliableas false. - Closely related languages. Norwegian and Danish, or Croatian and Serbian, share most of their trigrams. Check the runner-up candidates when confidence is low.
- Mixed-language text. A profile comparison assumes one dominant language. A paragraph that switches mid-way will return whichever language owns most of the characters.
- Noise. URLs, code, hashtags and product codes add trigrams that belong to no language. Strip them before detection.
- Rare languages. A language outside the supported set returns the nearest statistical match rather than an exact one.
Using it in practice
You can paste text into the language detector to see the winning language, a confidence value and the runner-up candidates. From code, call GET /v1/language?text=Bonjour; the request is analysed locally, the text is not sent to a third-party vendor or an AI model, and nothing is logged. The free tier allows 1,000 requests per day with no signup, and the API documentation describes the response fields.
Common uses include choosing a translation source language, setting a page's lang attribute, and routing support tickets to the right team. Another useful pattern is pairing text language with network context. Language is a signal about the writer, not the connection, so it will often disagree with where the connection comes from; a Spanish-speaking user in France or on a VPN is entirely normal. If you want to compare the two signals, a VPN and proxy check on the IP address helps you see whether a location mismatch has a network explanation, and the User-Agent parser exposes the browser and device context. Treat any mismatch as a hint, never as proof that something is wrong.