When I added a Traditional/Simplified Chinese converter to my little text-tools site, I assumed it'd be the easy one — swap a few thousand characters for their counterparts and call it done, same idea as the Unicode font-swap trick behind my Instagram font generator. Then I typed a single character, 干, into the input box and watched it turn into three completely different traditional characters depending on which word it was sitting inside. That's when I actually sat down and read how the conversion library I'd pulled in works, instead of assuming "it's just a lookup table."
The tool uses opencc-js, the JS port of the Open Chinese Convert project, and Converter({ from, to }) doesn't hand you one flat map. It picks named dictionary groups — for converting from simplified Chinese, that's a character-level dictionary followed by a phrase-level one, chained in order:
Each dictionary gets loaded into its own trie, and the tries run in sequence over the text:
Inside a single trie, the walk isn't "replace this character" — it's "find the longest matching key starting here, and remember it as you go deeper":
So a four-character phrase entry beats a two-character entry, which beats a bare single character, at the same starting position. That's the whole mechanism that makes context-sensitive-looking behavior possible without anything resembling grammar — it's just "prefer the longest known phrase."
Here's why I noticed this at all. The single-character dictionary (STCharacters) has exactly one entry for 干:
If that were the whole story, every 干 in your text would become 幹 — the "do/work" character. But STPhrases (the phrase-level dictionary loaded right after it) contains lines like these, pulled straight from the bundled data file:
Three different outcomes for the same input character, entirely dependent on which word it's part of. This isn't the converter "understanding" Chinese — it's a few hundred manually enumerated exceptions layered on top of the single-character default, each one long enough to win the longest-match check before the plain 干→幹 rule ever gets a chance to fire. It's real disambiguation, but it's disambiguation by memorized word list, not by parsing meaning.
The other thing that surprised me reading the component: none of the four conversion buttons call a single direct converter. They chain several:
Instead of one dedicated dictionary per every possible (source, target) pair, each button routes the input through a chain of converters that funnel it toward a common intermediate form before pushing it to the actual target. That only works because a trie-based converter is a safe no-op on text it doesn't recognize: if you run already-simplified text through a dictionary whose keys are Hong-Kong-specific traditional variants, none of those keys match, so nothing gets replaced and the text passes straight through. That's what makes it safe to shove text of unknown origin — simplified, Taiwan traditional, Hong Kong traditional, or Japanese kanji — through the same multi-hop pipeline without asking the user what they pasted in the first place.
The phrase table is a finite, hand-maintained list, not a model of the language. A rare compound word, a proper name, or a sentence structure nobody added to the dictionary just falls back to the plain per-character rule — so 干 quietly becomes 幹 again in any phrase the maintainers never saw. And because the UI chains converters (as above), a wrong substitution at the first hop becomes the literal input to the next hop; there's no later stage that can notice and correct it. The tool's own intro text is upfront about a related gap too — it flags that Taiwan/Hong Kong vocabulary differences (自行車 vs 腳踏車, "bicycle") aren't fully catalogued and suggests double-checking anything that matters. That admission is a good tell for what this really is: solid dictionary coverage, not linguistic understanding.
I ended up trusting the phrase-dictionary approach more than I expected going in — for everyday text it resolves ambiguous characters correctly far more often than a naive character swap ever could. I still wouldn't paste a contract through it without a native speaker checking the result, though. If you want to try it on your own text, I turned this into a small free tool: Traditional and Simplified Chinese Converter. No sign-up, paste and convert.
Available in other languages 線上繁簡體轉換器 — 繁體中文 在线繁简体转换器 — 简体中文 Traditional and Simplified Chinese Converter — English 繁体字・簡体字オンライン変換ツール — 日本語 번체 및 간체 중국어 변환기 — 한국어 Convertisseur de Chinois Traditionnel et Simplifié — Français Конвертер традиционного и упрощённого китайского — Русский Konverter für traditionelles und vereinfachtes Chinesisch — Deutsch Konverter Bahasa Mandarin Tradisional dan Sederhana — Bahasa Indonesia Convertidor de Chino Tradicional y Simplificado — Español Bộ chuyển đổi Trung Quốc Truyền thống và Đơn giản trực tuyến — Tiếng Việt ตัวแปลงภาษาจีนตัวเต็มและตัวย่อ — ไทย Konwerter Chińskiego Tradycyjnego i Uproszczonego — Polski Geleneksel ve Basitleştirilmiş Çince Dönüştürücü — Türkçe Convertitore di Cinese Tradizionale e Semplificato — Italiano Conversor de Chinês Tradicional e Simplificado — Português Traditioneel en Vereenvoudigd Chinees Converter — Nederlands Конвертер традиційної та спрощеної китайської — Українська