Quick Answer: Converting Hindi text between keyboard layouts means changing how the same words are encoded, not retyping them. Unicode stores Hindi as standard characters, while legacy layouts such as Kruti Dev and Chanakya store glyph codes. A converter maps one encoding to the other so text stays editable and displays correctly.
Before choosing a conversion method, it helps to separate three things that are often confused: the keyboard layout you type with, the character encoding that stores the text, and the font that displays it. A layout is simply the mapping between your physical keys and the characters they produce. Encoding is what actually lives inside the document. The font only decides how those stored characters look on screen.
Unicode is the standard encoding for Hindi. Each Devanagari character, matra, and conjunct has a defined code point, so the same text opens correctly on any modern device, in any application, without a special font installed. Legacy layouts work differently. Kruti Dev and Chanakya are font-based systems in which the stored codes are glyph positions rather than standard characters. Text typed in Kruti Dev looks correct only when the Kruti Dev font is applied; copy it elsewhere and it turns into meaningless Latin characters.
This distinction drives every conversion decision. Moving from a legacy layout to Unicode is a genuine encoding change: the glyph codes must be remapped to Devanagari code points, and conjuncts and matras have to be reassembled in the correct logical order. Moving between two Unicode-based layouts, by contrast, usually requires no conversion at all, because the underlying characters are already identical. The table below summarizes the practical difference.
| Aspect | Unicode (e.g., Mangal, Nirmala UI) | Legacy font layout (e.g., Kruti Dev 010, Chanakya) |
|---|---|---|
| What is stored | Standard Devanagari code points | Glyph positions mapped to Latin keys |
| Portability | Opens correctly anywhere | Requires the matching font installed |
| Search and spell check | Works normally | Usually fails |
| Editing behavior | Matras and conjuncts behave logically | Editing can break character order |
| Conversion need | None between Unicode layouts | Required to move to or from Unicode |
The practical takeaway: if your text is already Unicode and you only want to type with a different layout, you are changing input habits, not converting a file. If your text is in a legacy font, you need a real conversion step. For a hands-on walkthrough of the legacy-to-Unicode direction, see the Unicode to Kruti Dev converter, which handles both directions of the mapping in the browser.
Most people reach for a converter when a simpler fix would do. Use the following decision points to identify your situation before converting anything, since unnecessary conversion can introduce errors and extra work.
Two comparisons matter most in practice. First, browser tools versus installed software: browser tools need no installation and work across devices, but large volumes of text are easier to handle in a dedicated application or script. Second, one-off conversion versus repeatable conversion: if you convert the same kind of document regularly, an API or code-based approach saves time and avoids copy-paste errors. The comparison of Kruti Dev and Unicode converters covers how the main tool types differ, and the API and PHP conversion guide is the starting point if you need programmatic conversion.
Changing the layout you type with is separate from converting existing text, and the general workflow is similar across Windows, macOS, and mobile devices. The steps below describe the process without tying it to one operating system version, since menu names vary between releases.
This is the part people often call a "change in Kruti Dev font" workflow when they are already inside a Kruti Dev document: they want to keep typing the same way but see something different, or the reverse. Remember that switching the input layout changes what new keystrokes produce; it does not touch text that is already on the page. Existing legacy text still needs a converter.
See also: Change Font to Kruti Dev Online | Free Quick Tool
See also: Mangal to Kruti Dev 010 Font Converter (Free Online)
"Kruti Dev 010 to code" describes a slightly different goal from ordinary conversion. Instead of producing text you read on screen in Kruti Dev, you produce a machine-readable representation that survives without the font installed. There are two common interpretations, and both are useful.
Code points (Unicode). The most practical form is to convert Kruti Dev 010 text to Unicode and then read out the code points of the resulting characters. This gives you standard values such as the Devanagari block range 0900–097F, which any system can interpret. It is the right approach for databases, search indexes, and any application that must sort or spell-check Hindi text.
Escaped or entity form. For web pages and developer handoffs, the Unicode characters can be written as HTML numeric entities or escape sequences. This guarantees the Hindi renders correctly even if the page's font stack changes, and it keeps the text safe when copied between systems that might mangle raw Devanagari bytes.
| Target "code" form | Best for | Trade-off |
|---|---|---|
| Unicode text | Documents, email, apps | Requires a Devanagari-capable font to display |
| Unicode code points | Databases, search, sorting | Not human-readable at a glance |
| HTML entities / escapes | Web pages, developer handoff | Harder to edit by hand |
A useful sanity check: convert a short Kruti Dev 010 sample, confirm the Unicode output reads correctly, and only then extract code points or entities. If the intermediate Unicode is wrong, every downstream form will be wrong too.
Conversion requests usually come from a handful of recurring situations. Recognizing yours speeds up the process and helps you pick the right direction.
In each case the goal is the same: make the text display and edit correctly wherever it is used, without depending on a font the reader may not have.
Most failures fall into a few predictable patterns. The table below pairs each symptom with its usual cause and fix.
| Symptom | Likely cause | Fix |
|---|---|---|
| Hindi shows as Latin letters like "d" and "l" | Legacy text without its font applied | Convert to Unicode, or apply the correct Kruti Dev font |
| Matras sit beside the consonant | Unicode text with a legacy font applied | Remove legacy formatting; select a Unicode Devanagari font |
| Boxes or question marks | No Devanagari font on the device | Install a Unicode Devanagari font |
| Partial conversion | Mixed Unicode and legacy paragraphs | Separate and convert only the legacy sections |
| Digits changed unexpectedly | Latin vs Devanagari numeral mapping | Check dates, amounts, and serial numbers |
| Danda replaced by full stop | Punctuation not mapped | Restore dandas where the style requires them |
| Looks fine on desktop, broken on phone | Font missing on mobile | Keep a Unicode version for sharing |
Unicode text is portable: it displays correctly without installing a specific font, supports search, sorting, and spell check, and works across Windows, macOS, Linux, iOS, and Android. Legacy fonts look correct only where that font is installed, and copying the text elsewhere often produces gibberish. Mangal is itself a Unicode font, so moving from Mangal to Kruti Dev is a step back in portability but sometimes necessary for a specific template.
Reputable converters run the mapping in your browser, so the text does not need to be uploaded to a server. Still, avoid pasting confidential documents into unfamiliar tools, and keep a copy of the original until the output is verified.
Yes. Browser-based converters work on mobile, and there are apps that provide Hindi keyboards and conversion. Desktop font installation is usually not possible on phones, which is another reason to keep text in Unicode for mobile use.
Yes, if the output is Kruti Dev-encoded. The converted text depends on the Kruti Dev font to display correctly. If you need text that displays without installation, keep it in Unicode instead.
Check what the text looks like without any special font. If Hindi reads correctly, it is Unicode and you only need to change your input layout. If it looks like Latin gibberish until Kruti Dev is applied, it is legacy and needs conversion to Unicode.
Manual web tools are best for individual documents. For batches, use a script or API so the mapping is applied consistently, and always test on a few files before running the full batch.
Converting Hindi text between keyboard layouts is mostly about recognizing which encoding you have. Unicode text only needs a different input method; legacy text needs a real conversion, and a font dropdown change will not do it. When you need to convert font to Kruti Dev, choose the right variant such as Kruti Dev 010, convert first, then apply the font. When you need Kruti Dev 010 to code, go through Unicode and extract code points or entities from the verified output. Keep a Unicode master copy of every document, and you can move between layouts without losing the text.
It changes the characters, not the wording. The same Hindi words are re-encoded so they display and edit correctly in a different font system, such as from a legacy Kruti Dev layout to Unicode or the reverse.
Legacy fonts such as Kruti Dev map Latin keys to Hindi shapes. If the font is not applied, or the text is pasted where that font is unavailable, you see the underlying Latin characters. The text needs conversion, not just a font change.
No. Selecting a different font only changes how existing characters are drawn. If the characters belong to a legacy encoding, you must convert them with a converter tool to get proper Unicode Hindi.
This usually means Unicode text is being displayed with a legacy font applied, or the receiving application lacks a Devanagari-capable font. Remove the legacy font formatting and confirm a Unicode Hindi font is selected.
The viewing device or application does not have a font that covers Devanagari, or the text is not genuine Unicode. Install a Unicode Devanagari font and verify the source encoding before converting.
Yes, but convert only the Hindi portions. Sending English words through the Hindi mapping turns them into meaningless Hindi characters, so restore or isolate English segments before and after conversion.
The source is probably mixed: some paragraphs are already Unicode and others are still in a legacy font. Separate the two, then convert only the legacy sections.
Digits can come out as Latin 1–9 or Devanagari १–९ depending on the source layout and settings. Check dates, amounts, and serial numbers in the output and correct any mismatch.
Punctuation typed on an English keyboard may not map to Devanagari punctuation. Review sentence endings after conversion and replace full stops with dandas where the document style requires it.
Not directly. Converters work on text characters, so you first need to extract the text with OCR or obtain the original document. Images contain no editable characters to map.
Unicode is safer for sharing because it does not depend on the reader installing a specific legacy font. Kruti Dev output is still useful for publishers and templates that specifically require it, so keep a Unicode master copy.
Paste a sample into a plain-text editor. If the Hindi reads correctly without any special font applied, it is Unicode. If it appears as Latin gibberish until a legacy font is selected, it is legacy-encoded.
Font availability differs between devices. A legacy font installed on your machine may be missing on a phone. Unicode text with a widely available Devanagari font renders consistently across devices.
Yes. Keep the unconverted source until the output has been proofread and tested in its final application. If something fails, you can re-convert from the original instead of repairing damaged text.
Treating a font change as a conversion. Changing the font dropdown does not alter the characters, so the text remains in its original encoding and displays incorrectly wherever that font is unavailable.