Khek to Unicode — Khmer Legacy Font Converter

About this tool

For years, Cambodian offices typed their documents in legacy Khmer fonts — Limon for NGO reports and school handouts, ABC and Khek for ministry circulars and print-shop layouts. A file saved in one of those fonts does not contain Khmer characters at all: it stores Latin byte codes that only draw Khmer letters while the matching font is installed. Copy a paragraph out of one today and you get strings like `sYsþI` instead of សួស្តី — unsearchable, untranslatable, unreadable on any device that lacks the font. This page converts that legacy text into Unicode Khmer, the encoding every modern phone, browser and website reads — Limon to Unicode, ABC-Zwsp to Unicode and Khek to Unicode, all from the same pane. Pick the encoding yourself or leave the selector on Auto-detect: the Limon to Unicode path, the ABC-Zwsp path and the Khek path each apply their own byte table, and the detector picks the one whose decode looks like real Khmer. Everything runs in your browser — paste the legacy text, press Convert, copy or download the result. What it does not do: it does not translate meaning, it does not render legacy fonts on screen, and it does not go from Unicode back to a legacy encoding — the paired Unicode to legacy converter handles that direction. Characters with no entry in the chosen table pass through unchanged and are counted for you, never guessed at.

How it works

Pressing Convert runs a pure function in your browser — convertLegacyToUnicode in lib/khmer-legacy-converter/converter.ts — with the encoding you selected. Under Auto-detect, the page first decodes your text under each of the three tables and scores how plausible each result is as real Khmer: a wrong table produces consonant clusters that cannot exist, like a subscript sign glued to a letter that has no subscript form, or vowel signs floating with no base consonant, so the highest-scoring table is usually the right one. The conversion pass then walks your text matching the longest known byte sequence first — legacy fonts pack some Khmer glyphs into two- and three-byte combinations that a naïve one-byte map scrambles — before falling back to the single-byte table. Those bytes decode in visual order, whereas Unicode demands logical order, so a reorder pass (reorder.ts: unicodeReorder) arranges every cluster the way Unicode specifies — subscripts, vowel signs and shifters land where a search box expects them. Characters the table does not define pass through unchanged and appear in the unmapped-characters chip under the output. Inputs over 10 KB convert inside a Web Worker so the page stays responsive; smaller text runs on the main thread. Your text never leaves the browser — the only telemetry is an anonymous usage event carrying counters such as length and unmapped count, never the text itself.

Use cases

• Opening an old .doc or .pdf and seeing garbled characters like sYsþI bgb¥Ún — paste the legacy text and get clean សួស្តី បងប្អូន back.
• A librarian digitising pre-2010 Cambodian publications whose source files are Limon-encoded and whose target repository requires Unicode text.
• A government officer migrating a Khek-encoded form template into a modern Unicode-based document system.
• A developer importing a legacy CSV of Cambodian records whose Khmer name column is Limon bytes, needing Unicode for a modern search index.
• A website team moving a Limon-era blog over to a current CMS that requires Unicode for proper indexing and rendering.
• A translator receiving a Khmer source file in ABC-Zwsp and needing clean Unicode to paste into a CAT tool.
• A researcher processing a corpus of 1990s–2000s Khmer newspapers whose text follows the original Limon encoding.

Verified conversion examples

Frequently asked questions

• What is the Khek encoding?

  Khek is a legacy Khmer font found mostly in government and administrative documents — official forms, provincial correspondence and institutional templates from the pre-Unicode era. Like Limon and ABC-Zwsp it stores Khmer as Latin byte codes, so a Khek document read without the font is Latin-1 gibberish until the byte table converts it back.

• Khek and Limon look similar as raw bytes — how do I pick?

  The two tables share a large surface, so a wrong pick can still convert most characters — with a few letters landing wrong. The reliable check: convert a line under the Khek table and read it; fluent Khmer means you chose right, scattered plausible-but-wrong characters mean it was really Limon. Or leave the selector on auto-detect, which scores both tables against real Khmer cluster rules.

• Is Khek still used anywhere today?

  Occasionally, yes — some institutional templates and unreplaced government printing setups still expect it, which is why the reverse direction exists too. For new work there is no reason to create Khek documents, but a large archive of finished Khek material still circulates in Cambodian offices and needs exactly this conversion.

• Why does my Khek output still contain a few Latin letters?

  Leftover Latin-1 characters are bytes the Khek table does not define — either stray non-Khmer text in the document or characters the font never assigned. The unmapped chip under the output counts each distinct leftover with its code point, so you can see at a glance whether the document is really Khek or mixed with another font.

Data and accuracy

Content last reviewed 8 November 2026