Skip to main content
ATS Free For All
Sign in
Back to blog
Available in:

Turkish Characters and Encoding Degradation

By Umut Barış Terzioğlu · · Updated

Turkish CVs use letters outside the basic English alphabet: ç, ğ, ı, İ, ö, ş and ü. German CVs add ä, ö, ü and ß, and many names carry accents such as é. These special characters look fine on screen. What matters is whether they are still the same letters once an applicant tracking system has pulled the text out of your file. Usually they are. When they are not, your name, headings and skills arrive as different words from the ones you wrote.

What the damage looks like

Three patterns are common. The left side is what you wrote, the right side is what the extracted text contains.


İş Deneyimi        ->  İş Deneyimi
München, Straße    ->  München, Straße

This is mojibake: the text was stored correctly as UTF-8, but a program along the way read it as an older single-byte code page such as Windows-1252, turning every special letter into two wrong characters.


İş Deneyimi        ->  ?? Deneyimi
Gülşen Yıldız      ->  G�l�en Y�ld�z

Here the letters are gone. Either the PDF draws the right shapes without saying which letter each shape stands for, or a system converted the text to a character set that has no such letters. The result is a question mark, a replacement character (�) or a placeholder such as (cid:12).


Mühendislik, İstanbul  ->  Muhendislik, Istanbul

The third pattern is quieter: the marks are stripped, either by a system that simplifies text or by someone typing without a Turkish keyboard. The result is readable, but a search for "Mühendislik" may miss it, and your name no longer matches your passport or LinkedIn profile.

When a heading is damaged, a parser may not recognise where your experience section starts, and the entries under it can land in the wrong field.

Where it comes from

A PDF stores instructions to draw glyphs from a font and, ideally, a ToUnicode table that maps each glyph back to a character. A parser needs that table to turn the page back into text. If the exporting program leaves it out or writes it wrong, the page looks perfect while the text layer is broken. Decorative fonts, text converted to outlines in design tools and some print-to-PDF routes are the usual suspects. If a font has no glyph for ş or ğ at all, the word processor swaps in another font for those letters or shows an empty box (□).

Mojibake has a different cause: the file is intact, but a program further along decodes UTF-8 as a single-byte encoding, which breaks German and Turkish letters alike. A related failure hits Turkish harder. When a system converts text to Latin-1 (ISO-8859-1), ä, ö, ü and ß survive because Latin-1 contains them, while ş, ğ, ı and İ, which need Latin-5 (ISO-8859-9) or Unicode, become question marks.

A two-minute check

  1. Open the PDF you plan to send, select all, copy, and paste into a plain text editor.
  2. Read your name, headings, city and a few skills letter by letter.
  3. Search the pasted text for the sequences below, for the replacement character � and for "(cid:". Any hit means the text layer is damaged.
  4. In the PDF viewer, search for a word with a special letter, such as your surname. If the viewer cannot find a word you can see on the page, the text behind it does not match.

ü -> ü    ö -> ö    ç -> ç    ä -> ä    ß -> ß
ı -> ı    İ -> İ    ğ -> ÄŸ    ş -> ÅŸ

This is the copy-and-paste test from part 1 on ATS text extraction, narrowed to the letters that break most easily.

How to export a file that keeps its letters

  • Use a widely available font that covers your language, such as Arial or Calibri, rather than a decorative one.
  • Export straight from Word, LibreOffice or Google Docs. If the result fails the check above, try another route, such as a different program or exporting instead of printing, and test again.
  • In design tools, do not convert text to outlines or images.
  • Keep the real spelling. "Mueller" or "Is Deneyimi" sidesteps the encoding problem but changes your words: your name stops matching your documents, and a keyword may stop matching the job ad.
  • If the portal accepts DOCX, consider it. DOCX stores text as Unicode and needs no glyph mapping table. Part 5 on PDF or DOCX CVs compares the two formats.

How the checker reports it

Garbled special letters in the extracted text are reported as a Parseability finding; multilingual support lists what else is handled per language. You can also paste the text from step 1 into the quick test. It runs in the browser without an account and applies the same Parseability checks, broken characters included.