Fix Hindi text showing as symbols or English letters

Two kinds of Hindi text look broken on screen, and people often try the same fix for both. That rarely works. The strings भारत and Hkkjr are produced by different mistakes, and each needs a different repair.

This guide shows how to tell them apart, what causes each, and what to do.

The quick test

Look at the characters themselves.

भारत is made of accented Latin letters, the ¤ sign and other Western symbols. The text is Unicode Hindi that was read with the wrong character encoding. This is called mojibake.

Hkkjr is made of ordinary English letters that look like they could be an English word. The text is legacy Hindi stored in a font such as Kruti Dev or DevLys. It is not broken at all; it is just being shown without its font.

□□□ or empty boxes mean the text is Unicode but the device has no font that covers Devanagari.

भा is an HTML character reference that was never rendered. The numbers are Unicode code points written in decimal.

Once you know which one you have, the fix is usually one step.

Case 1: mojibake (भारत)

Hindi letters take three bytes in UTF-8. For example, भ is E0 A4 AD. If a program reads those bytes as Windows-1252 instead of UTF-8, it shows each byte as a Western character: à, ¤ and an invisible soft hyphen. The bytes are still there; only the interpretation is wrong.

This happens when:

• A web page is missing <meta charset="utf-8"> or the matching HTTP header.
• A CSV file without a byte-order mark is opened in Excel, which then reads it in the system’s legacy code page.
• A database column or connection is set to latin1 instead of utf8mb4.
• A file saved as UTF-8 is opened with an “ANSI” or “Windows-1252” setting.

The fix: paste the text into the fix broken text tool. It maps each character back to its byte and decodes the bytes as UTF-8. It also handles double encoding (à ¤­), HTML character references, JavaScript and JSON escapes (\u092d), and percent-encoded UTF-8 from a URL.

For a file, re-open it with the correct encoding. In Excel, save as “CSV UTF-8” or import with the UTF-8 option. In a database, use utf8mb4. Fixing the source prevents the problem from coming back.

Not every mojibake string can be repaired. If the text has become question marks (????) or the replacement symbol (�), the original letters were replaced when the file was saved and cannot be recovered from the text alone.

Case 2: legacy font (Hkkjr)

This is not an encoding error. The file contains English letters because a legacy font was used to draw Devanagari shapes over them. Hkkjr is भारत when Kruti Dev 010 is applied. fgUnh is हिन्दी. dk is का, ds is के, and esa is में.

The fix: convert the text to Unicode with the converter for the font that wrote it. For Kruti Dev, use Kruti Dev to Unicode. For DevLys or Chanakya, find the font by name with the font finder and open its converter.

If you do not know the font, paste a sentence into the font detector. It runs the text through each profile and ranks the results. Very short samples can be ambiguous, because Kruti Dev and DevLys share most key positions; a sentence or two gives a better answer.

What not to do: do not select the text and change its font to Mangal. That changes how the letters are drawn, not what they are. You will see the same English letters in a different typeface.

Installing the legacy font is a valid stopgap if you only need to read the document on one computer. It does not help on phones, in Google Docs or on websites, and the text remains hard to search.

Case 3: boxes (□□□)

The text is already Unicode. The device simply has no font that covers Devanagari, which happens on some systems and in some PDF viewers.

The fix: choose or install a Unicode Devanagari font such as Mangal, Nirmala UI, Kokila or Noto Sans Devanagari. In a browser, the page may need a web font. In Word, select the text and pick a font that includes Devanagari.

Running the text through a legacy converter will not help, because nothing is wrong with the characters.

Case 4: HTML references (भ)

The text was written for a web page but is being shown as plain text, or a CMS escaped it twice.

The fix: the fix broken text tool decodes decimal and hexadecimal references. If you are editing the page, render the text instead of escaping it.

Mixed documents

A single Word file can contain both problems: some paragraphs in Kruti Dev, some in Unicode, and some copied from a web page with broken encoding. The Word file converter is the right tool here. It reads the font of each run and converts only the legacy text, keeping tables, images and styling.

For plain text, convert one paragraph at a time and check each result. Mixing the two repairs usually makes things worse.

A decision table

Preventing it

• Save text files as UTF-8.
• Put <meta charset="utf-8"> first in the <head> of a web page, and send the matching HTTP header.
• In Excel, use “CSV UTF-8”, not plain CSV.
• In MySQL use utf8mb4; in PostgreSQL use UTF8.
• Do not copy legacy-font text into a Unicode-only system. Convert it first.

Most Hindi “broken text” is one of these two problems. Identify the pattern, use the matching tool, and the text usually comes back in one paste.