Full-Width Half-Width Converter

Full-width and half-width forms are distinct Unicode characters, not merely a font-size setting. Section 18.5 of the Unicode 17 Core Specification explains their origin in East Asian systems that displayed double-byte characters in two cells and ASCII or similar single-byte characters in one. Unicode kept the corresponding forms so older mixed-width text could be converted without losing those distinctions.

This converter deliberately applies a smaller, auditable set of replacements instead of running generic Unicode compatibility normalization.

ASCII and space

In the full-width direction, each printable ASCII character from U+0021 through U+007E maps to the character at U+FF01 through U+FF5E. ASCII space U+0020 maps to ideographic space U+3000. The reverse direction maps only those full-width counterparts back to ASCII. Unicode notes that the full-width form of ASCII space is unified with U+3000, while the Halfwidth and Fullwidth Forms chart records the wide mappings for punctuation, digits and Latin letters.

The third row shows the boundary clearly. The ASCII digits and space change, supported half-width Katakana changes, and 東京 plus the emoji remain untouched.

Katakana, punctuation and sound marks

The tool maps the documented half-width Katakana set, Japanese punctuation and prolonged sound mark through an explicit table. The Unicode character names list for U+FF00 to U+FFEF gives the narrow correspondences used for U+FF61 through U+FF9F, including ｡ with 。, ｢ with 「, ･ with ・, and ｱ with ア.

Voiced and semi-voiced syllables use explicit pairs. For example, ｶﾞ maps to ガ, ﾊﾟ to パ, and ｳﾞ to ヴ. The table also includes the supported voiced ﾜﾞ and ｦﾞ pairs. Unsupported kana such as ヰ, ヱ, ヸ, ヹ, ヵ and ヶ remain unchanged rather than being guessed or transliterated.

U+FF9E and U+FF9F are handled as the strict half-width counterparts of combining U+3099 and U+309A. The spacing marks U+309B ゛ and U+309C ゜ are different characters and remain unchanged. This distinction matters when inspecting output at the code-point level.

A precise normalization caveat

This is not NFKC. Unicode Standard Annex #15 classifies width variants as compatibility equivalents and shows that NFKC also changes many unrelated compatibility forms. This tool avoids those wider effects by using only its documented tables.

There is one intentional composition detail for voiced Katakana. Precomposed ガ and the canonically equivalent sequence カ followed by U+3099 both narrow to ｶﾞ. Widening that result produces the customary precomposed ガ. Therefore, the visible reading is retained, but every original code-point sequence is not guaranteed to round-trip. The same principle applies to the supported voiced and semi-voiced pairs.

The tilde family is another useful test:

ASCII tilde U+007E and full-width tilde U+FF5E form a mapped pair. Wave dash U+301C 〜 is not that character, so it stays unchanged in both directions.

What remains unchanged

Tabs, line breaks and non-breaking space U+00A0 are preserved. So are Hiragana, Kanji, emoji, half-width Hangul, unsupported kana, Arabic-Indic digits, Eastern Arabic-Indic digits and all other unlisted code points. The converter does not translate words, change Hiragana into Katakana, parse numbers, transliterate Japanese or clean up Unicode generally.

The Japanese Standards Association catalog entry for JIS X 0201:1997 identifies the Japanese standard for 7-bit and 8-bit coded character sets. That standards context helps explain legacy Roman and Katakana repertoires, but this browser tool does not inspect a file encoding or certify conformance with JIS X 0201 or any other encoding. It operates only on the Unicode text already supplied by the browser.

Privacy and input limit

Conversion runs in the browser. The source text and selected direction are stored in sessionStorage for the current session so they survive the three-step interface. The source is not sent to our servers, placed in the URL or submitted to the server. Starting over removes the saved session value. Clipboard managers, browser extensions and the destination where you paste the result remain outside the tool’s control.

The limit is 10,000 Unicode code points, not 10,000 UTF-16 code units. This means a supplementary character such as an emoji counts once. Some valid inputs may contain different numbers of code points after conversion because a supported base Katakana plus combining sound mark can become one precomposed character. The limit controls input size; it is not a promise of code-point-for-code-point output length.