locl feature, we read it straight out of the GSUB table below.locl: —
toUpperCase(), CSS text-transform and most databases produce. Right is the Turkish rule.| Language | Coverage | Missing |
|---|
Drop a TTF, OTF or WOFF file and this page tells you whether the font really supports Turkish characters — ş Ş ğ Ğ ı İ ö Ö ü Ü ç Ç — by drawing every one of them from the font's own outlines. It is free, needs no sign-up, and your font file never leaves your device: everything is parsed in the browser.
Checking whether a font supports characters is only half the job. The other half is the dotless i. Turkish has four i-letters where English has two, so istanbul must uppercase to İSTANBUL, not ISTANBUL, and IĞDIR must lowercase to ığdır, not iğdir. This tool renders the wrong and the right result side by side in your font — and warns you when the font cannot even draw the correct one.
Wakamai Fondue and FontDrop! both show a Unicode block listing: they will tell you the font covers “Latin Extended-A” and let you scroll a glyph table. Neither answers the question a Turkish designer or developer actually has — is this font safe for Turkish text? — and neither tests language-specific case behaviour at all. For a global tool, Turkish is an edge case buried in a block chart. Here it is the whole point: the twelve characters are checked by name, the dotless i rule is executed live, and a font that has ş but no İ is called out instead of scoring a green tick.
Drop your TTF, OTF or WOFF font into the box on the left. It is read locally — no upload, no account.
Read the verdict and the twelve character cells. Red dashed boxes are characters the font does not have; amber ones exist but have no outline.
Check the dotless ı / dotted İ conversion test, type your own text, then download the CSV report for your client or team.
Nine times out of ten a font covers Latin-1 — which already includes ö, ü and ç — but stops there. ş, Ş, ğ, Ğ, ı and İ live in Latin Extended-A, so they are the six that go missing, and the six this page marks as critical. The symptom is familiar: text looks fine until a Turkish word appears, then letters turn into boxes, or the browser silently swaps in a completely different fallback font for those letters and your headline changes shape mid-word.
The second failure is subtler and no glyph table will catch it. A font can contain all twelve letters and Turkish text still comes out wrong, because the software uppercased it with the English rule. Titles set in CSS text-transform:uppercase without lang="tr", spreadsheet exports, and database UPPER() calls all produce ISTANBUL. That is a text-processing bug, not a font bug — but you will see it in the same headline, so this page tests both.
Once you know the font has the letters, the next question is whether you are allowed to ship it. That is a different file entirely — the OS/2 fsType bits — and it is what our Font Embedding License Checker reads. Together the two make up the font toolkit: one answers “does it have the letters”, the other “may you embed it”.
Drop the TTF, OTF or WOFF file into this page. Each of the twelve Turkish characters is looked up in the font's character map and then drawn from the font's own outlines, so you see the real glyph instead of a claim. Anything the font does not contain is shown as a red dashed box, and characters that exist but have no outline are flagged separately.
Most likely the two dotted-i characters. Turkish uses four letters where English uses two: i, İ, ı and I. Standard JavaScript, CSS text-transform, Word and most databases uppercase istanbul to ISTANBUL, which is wrong in Turkish — it must be İSTANBUL. If the font is missing İ (U+0130) or ı (U+0131), even correct software produces a broken word, because the right character has no glyph to draw.
Turkish has a dotless ı whose capital is I, and a dotted i whose capital is İ. The dot is a letter difference, not decoration, so the mapping i to I is wrong in Turkish. This page renders both the naive result and the Turkish-locale result with your font side by side, so you can see whether the font can even draw the correct one.
No. The font is parsed inside your browser with opentype.js and never leaves your device. Nothing is stored, and the CSV report is generated locally too. That matters for commercial fonts you are only licensed to hold locally.
TTF, OTF and WOFF. WOFF2 is not supported, because decoding it in the browser needs a Brotli font decompressor of well over a megabyte, which we deliberately do not load. Convert the WOFF2 back to TTF or test the TTF the WOFF2 was built from — the character set is the same.