Skip to main content

Home › About

About Transliteration

Transliteration is a free tool for converting text into the Latin alphabet. This page says who builds it, which romanization standard each language follows, and where those standards come from, because for a tool like this those are the things worth knowing.

Who Builds This

Transliteration is developed and operated by Space Bits, S.L., a company registered in Spain (NIF ESB64776271, Manresa, Barcelona). Full company details, including our commercial registry entry, are on our Legal Notice page.

Engineering
Ferran Sarrió Hernández

Web developer. Responsible for the transliteration engine, the Unicode handling and the site itself.

LinkedIn
Company
Space Bits, S.L.

Operator of the site, based in Manresa, Barcelona.

LinkedIn spacebits.es
We are not linguists. Space Bits handles the technical implementation; the linguistic decisions are not ours to make. Each conversion is based on a published romanization standard, an established convention, or a specialist-maintained library, and we identify the source for each language below. Where a standard is ambiguous or a script does not encode enough information to convert reliably, we say so rather than guessing.

Why We Built Transliteration

Most transliteration tools online treat every input the same way: run every word through one fixed set of rules and hope for the best. That approach breaks down often, because pronunciation-based conversion has real ambiguity: the same word can sometimes be represented more than one accepted way in the target script.

Our engine combines a curated dictionary of common words and exceptions, which resolve exactly, with a rule-based phonetic engine as a fallback for everything else. We're upfront in our FAQ about which romanization system each language pair follows and where results can vary between tools, rather than overselling accuracy we can't guarantee.

The site itself is organized around focused sections for the languages we currently support, rather than one page trying to rank for everything without context.

Where Each Conversion Comes From

We don't invent our own romanization standards. Each language is based on an established standard or a specialist-maintained library, and where we adjust the output we say exactly how. This is what each one uses:

Romanization standard and implementation source for each supported language
Language Standard Implementation / source
Chinese Hanyu Pinyin overtrue/pinyin, an open-source library with word-level dictionary matching
Japanese Modified Hepburn, BGN/PCGN variant Unicode CLDR, via ICU (kana only; kanji are left unchanged)
Korean Revised Romanization of Korean Unicode CLDR, via ICU
Russian BGN/PCGN-style Unicode CLDR, via ICU
Tamil, Telugu, Kannada,
Bengali
ISO 15919-based Unicode CLDR, via ICU, unmodified
Hindi, Marathi,
Gujarati, Punjabi
ISO 15919-based, with documented pronunciation adjustments Unicode CLDR, via ICU, plus two adjustments of ours (see below)
Malayalam ISO 15919-based, with one corrected vowel Unicode CLDR, via ICU, plus one correction of ours (see below)

About the CLDR rows. These use the Unicode CLDR transliteration data, accessed through the ICU library. CLDR's stated policy is to follow established authorities where they exist; for several scripts these are the romanization tables of the UNGEGN Working Group on Romanization Systems, the United Nations body that agrees romanization systems for geographical names.

Our two adjustments to the Indo-Aryan output. For Hindi, Marathi, Gujarati and Punjabi we remove the disambiguation apostrophes ICU inserts, and we drop the silent word-final vowel that these languages write but do not pronounce, so that धन्यवाद reads as "dhanyavad" rather than "dhan'yavada". That deletion stops at a consonant cluster, where the vowel is pronounced and dropping it would leave something unsayable: महाराष्ट्र stays "mahārāṣṭra" and सत्य stays "satya". Both changes are documented in the source code.

Why Tamil, Telugu, Kannada and Bengali get neither. Those languages write the final vowel and pronounce it, so deleting it would be wrong: ಕನ್ನಡ is "kannaḍa", not "kannaḍ". We also keep their apostrophes, because there the apostrophe does real work: it separates a doubled consonant from a nasal plus consonant, and removing it would make the result ambiguous.

Our one correction to the Malayalam output. The CLDR rules leave the two vowel signs of the "o" series undecomposed, so ൊ comes back as "eā" and ോ as "ēā" instead of "o" and "ō". That is not valid output in any romanization system, and it affects very common words and place names: കഥഃംി would otherwise read "keācci" rather than "kocci". We substitute those two sequences and nothing else. On a test set of sixteen Malayalam words, raw ICU gets ten right and the corrected output gets all sixteen. The diphthong signs ൌ and ൗ are lost by ICU in a way we cannot recover from its output, which remains a known limitation.

To be precise about what this means: the result is a derived romanization, not strict ISO 15919. CLDR's own Indic transliterations already depart from the standard in places, partly to stay reversible, and our schwa adjustment departs from it further. We optimise for a reader who wants to know how a word sounds. If you need output that conforms exactly to ISO 15919 for academic or bibliographic use, this tool is not the right source.

Get in Touch

Found an incorrect conversion, have a feature request, or just want to say hello? We'd like to hear from you.

Contact Us

Changelog

23 October 2026 Pages on Tamil, Bengali and Telugu, and where English to Indic stands
  • Published a page on Tamil transliteration covering the ISO 15919 output, the letters that need diacritics, and why standard romanization differs from conventional spellings such as Chennai.
  • Published a page on Bengali transliteration explaining the inherent vowel, which is why কলকাতা romanizes as "kalakātā" and is said "Kolkata", along with the competing romanization systems and the script Bengali shares with Assamese.
  • Published a page on Telugu transliteration, including an explanation of the apostrophe in results such as "am'ma", which marks a doubled consonant and keeps the conversion reversible.
  • Tested two open phonetic schemes for English to Tamil typing, Azhagi and Jaffna, on ten everyday words: three and two correct respectively. The results are on that page, rather than shipping a converter we already know to be unreliable.
  • Published a page on Malayalam transliteration covering the chillu letters, the difference between a standard romanization and Manglish, and the vowel defect described below.
  • Improved the Japanese romanization. It was writing long vowels the way a keyboard does rather than the way Hepburn does, so とうきょう came back as "toukyou" instead of "tōkyō" and ありがとう as "arigatou" instead of "arigatō". We now use the BGN/PCGN variant of modified Hepburn, which uses macrons.
  • Changed what happens when Japanese text is written entirely in kanji. The tool was suggesting you switch to Chinese, which would have given the Chinese reading of the characters: 東京 as "dōng jīng" rather than "tōkyō". It now says plainly that it cannot read kanji yet instead of pointing you at a wrong answer.
  • Published a page on Marathi transliteration covering ळ, the letter Hindi does not have, why महाराष्ट्र keeps its last vowel when नमस्कार does not, and the Marathi place names.
  • Fixed the word-final vowel rule for Hindi, Marathi, Gujarati and Punjabi. It was deleting the vowel after consonant clusters, where it is actually pronounced, so महाराष्ट्र came back as "mahārāṣṭr" instead of "mahārāṣṭra" and सत्य as "saty" instead of "satya". On a 28-word test set this took the output from eighteen correct to twenty-eight.
  • Moved Kannada out of that group entirely. It is a Dravidian language and does pronounce its final vowel, so ಕನ್ನಡ is "kannaḍa" and ಕರ್ನಾಳಕ is "karnāṭaka"; we were returning both without the last letter.
  • Fixed a defect in the Malayalam output. The CLDR rules were leaving the vowel signs ൊ and ോ undecomposed, so കഥഃംി came back as "keācci" instead of "kocci" and കോബിക്കോറ് as "kēāṡikkēāṭ". On a sixteen-word test set this took the output from ten correct to sixteen.
  • Re-checked every romanization printed on the site against the ICU data itself and corrected two: அம்மா is "am'mā", not "ammā", and বাংলা is "bānlā", not "bāṁlā".
  • Split the sourcing table above by how each language is actually processed. It previously described nine languages as receiving two adjustments when only five of them do.
22 October 2026 Chinese surname readings, and a page about Chinese
  • Added an option to read Chinese input as a personal name, which uses the surname readings: 单 is "dān" in ordinary text but "shàn" as a surname.
  • Published a page on Chinese transliteration covering Pinyin, Wade-Giles, tone marks and the characters whose reading depends on the word.
26 August 2026 Sourcing made explicit
  • Documented the romanization standard and implementation source for every supported language, including the two adjustments we make to the Indic output.
  • Named who builds the site, and stated plainly that we are not linguists and rely on external standards.
12 August 2026 Four more Indic scripts
  • Added Marathi, Gujarati, Kannada and Punjabi, bringing the total to thirteen languages.
  • Published a full explanation of what transliteration is, including how it differs from translation and transcription.
11 August 2026 Malayalam support
  • Added Malayalam to Latin romanization, bringing the total to nine languages.
  • Clarified throughout the site that every conversion here is romanization: transliteration into the Latin alphabet specifically.
27 July 2026 Public launch
  • Launched with eight languages: Chinese, Tamil, Hindi, Japanese, Russian, Korean, Bengali and Telugu, all converting into the Latin alphabet.
  • Added automatic detection of the source writing system, so pasting text is usually enough.
  • Chinese uses word-level dictionary matching rather than character-by-character conversion, which resolves readings that change depending on the word.
20 May 2026 Development starts
  • With the research done, we began building the tool in whatever time we could set aside between other work.
  • The first decision was scope: only conversions into the Latin alphabet, and only where an established standard already existed to follow.
10 March 2026 Where this started
  • We noticed how often people need to read a name or a phrase written in a script they can't read, and how much of what's available online returns a translation instead of a transliteration.
  • We spent the following weeks researching romanization standards and what existing tools actually do.

Last updated: 23 October 2026