BlogText

Korean romanization: Revised Romanization vs McCune-Reischauer

Why the same Korean name shows up spelled two different ways, how the official Revised Romanization differs from the older McCune-Reischauer system, and which one to use when.

The Korean surname 김 is written Kim on most passports, but the city 부산 is officially Busan while older maps say Pusan, and 이 is romanized Lee, Yi, or I depending on who you ask. None of these are mistakes — they come from different romanization systems, plus a layer of personal-name tradition that ignores the systems entirely. If you've ever had to pick one spelling and commit to it, knowing which system you're in saves a lot of second-guessing.

Why one Korean word maps to several spellings

Romanization is transliteration: representing one writing system in another. Hangul records sounds precisely, but English spelling doesn't map cleanly onto Korean sounds, so any romanization has to make choices — especially for consonants that sit between English voiced and voiceless sounds, and for vowels English has no letter for. Different systems made those choices differently, and two have dominated.

Revised Romanization (RR) — the official one

Revised Romanization of Korean is the system the South Korean government adopted in 2000, and it's what you see on road signs, station names, and government documents today. Its defining trait is that it uses only plain ASCII letters — no diacritics, no apostrophes — which is exactly why it works on signage and in URLs.

Its consonant choices are the most visible difference:

  • 부산 → Busan (not Pusan)
  • 대구 → Daegu (not Taegu)
  • 제주 → Jeju (not Cheju)
  • 광주 → Gwangju (not Kwangju)

RR represents the relevant consonants with b/d/g/j where the older system used p/t/k/ch. The vowels ㅓ and ㅡ, which have no English equivalent, become the digraphs eo and eu — so 서울 is Seoul and 인천 is Incheon. If you're generating a spelling for anything official, public, or machine-readable, RR is the default.

McCune-Reischauer (MR) — the older standard

McCune-Reischauer, from 1937, was the dominant system for most of the 20th century and is still standard in much of academia, in North Korea, and in older books and maps. It aims to reflect pronunciation more closely for an English reader, and it pays for that with diacritics and apostrophes:

  • The breve marks vowels: ㅓ is ŏ and ㅡ is ŭ, so 서울 is Sŏul.
  • An apostrophe marks aspiration: ㅋ is k' versus ㄱ as k, ㅌ is t' versus ㄷ as t.

That's why you'll see Pusan, Taegu, and Kyŏngju in older texts. MR is more phonetically informative, but the special characters are fragile — they get dropped in plain-text systems, mangled in URLs, and are awkward to type — which is the practical reason South Korea moved away from it.

Hangul Revised (RR) McCune-Reischauer (MR)
부산 Busan Pusan
대구 Daegu Taegu
서울 Seoul Sŏul
경주 Gyeongju Kyŏngju
김치 gimchi kimch'i

Personal names are their own rule

Here's the catch that no system resolves: personal names follow neither RR nor MR consistently. Koreans are free to romanize their own names as they like, and family spellings have hardened over generations. So 김 is almost always Kim (not RR's Gim), 이 is usually Lee or Yi, and 박 is Park (not Bak). When you're romanizing a person's name, the right answer is whatever that person already uses — a romanizer can only give you the systematic default, which a name may well override.

Which to use

  • Revised Romanization for anything public, official, or machine-handled: signage, addresses, URLs, software. It's the current standard and stays intact in ASCII.
  • McCune-Reischauer when you're matching an academic citation, pre-2000 sources, or North Korean material that already uses it.
  • A person's own spelling for their name, always, over either system.

A romanizer applies the systematic rules; it can't know that 이 wants to be Lee. Our Korean romanizer converts Hangul to Revised Romanization in the browser, which covers place names, words, and a sensible default for names you then adjust by hand. If your goal is specifically a URL-safe string, the related concerns of diacritics and collisions are covered in slugifying URLs.