Full-width to Half-width Converter

What this tool does

Chinese, Japanese and Korean typography includes wide versions of the Latin alphabet, the digits and most punctuation, so that they line up with ideographic characters in a grid. When that text is copied into a Western system the result looks almost right and behaves badly: a full-width email address fails validation, a full-width password does not match, and a search for ABC will not find ＡＢＣ.

This converter maps between the two forms so the text behaves as expected, while leaving everything that is not full-width ASCII completely alone.

Method

The conversion uses a fixed offset. Unicode deliberately placed the full-width forms of ASCII at U+FF01–U+FF5E, exactly 0xFEE0 above their half-width counterparts at U+0021–U+007E. Subtracting or adding that offset converts the whole range in one pass. The ideographic space U+3000, which sits outside that range, is mapped explicitly to and from the ordinary space U+0020.

Half-width	Code point	Full-width	Code point
A	U+0041	Ａ	U+FF21
1	U+0031	１	U+FF11
?	U+003F	？	U+FF1F
space	U+0020	ideographic space	U+3000

Example

Input	Direction	Output
ＡＢＣ１２３	→ half-width	ABC123
ｔｅｓｔ＠ｅｘａｍｐｌｅ．ｃｏｍ	→ half-width	test@example.com
ABC123	→ full-width	ＡＢＣ１２３

Why two forms exist at all

Full-width characters occupy the same square as a CJK ideograph, which is what makes them line up in a grid of Chinese, Japanese or Korean text. Half-width characters occupy half that width, which is what Latin text normally needs. Encoding both was a practical necessity in the era of fixed-width CJK terminals: a table of numbers written in Latin half-width forms looked ragged next to the surrounding ideographs, so full-width forms were added for ASCII letters, digits and punctuation.

The mapping is mostly mechanical — most full-width forms are U+FF01–U+FF5E, exactly the ASCII printable range shifted by 0xFEE0. U+FF21 is full-width A, U+0041 is ASCII A, and 0xFF21 − 0xFEE0 = 0x41. That single arithmetic relationship is why this conversion is lossless in both directions: every full-width ASCII form maps to exactly one ASCII character and back.

What is not a simple shift

Three cases break the neat arithmetic, and they are the ones that cause visible bugs:

Full-width	Half-width	Why it is special
U+3000 (ideographic space)	U+0020 (space)	Outside the FF01–FF5E block; it is the CJK space, not a shifted ASCII space
U+FF5E (～)	U+007E (~)	Maps to the ASCII tilde; the wave dash U+301C is a different character
U+FFE0–U+FFE6 (￠ ￡ ￢ ￣ ￤ ￥ ￦)	— left unchanged	A separate currency-and-symbol block with no unambiguous ASCII counterpart in every locale

The tilde row is the classic source of confusion. Japanese text uses ～ (U+FF5E) where Western text uses ~ (U+007E), and they are different Unicode characters that look similar. Converting to half-width gives the ASCII tilde, which is what a URL, an email address or a config value needs — but it is a change for display purposes, because the full-width form is broader and sits differently on the baseline.

The currency block is deliberately not folded. ￥ (U+FFE5, the full-width yen sign) and ¥ (U+00A5) are separate characters, and in a Japanese context the full-width form is the conventional one — converting it to the ASCII-range yen sign would change how the amount is read, not just its width. This tool leaves that block alone, and reports it as unchanged rather than inventing a mapping.

Where this conversion matters

• Usernames and emails entered with an IME. A Japanese or Chinese input method can produce full-width Latin characters without the user noticing. The address looks correct on screen and fails every lookup, because the stored bytes are not ASCII.
• Search and matching. A query typed half-width will not match text stored full-width unless both are normalised. This is a common cause of “no results” in CJK applications.
• Codes and identifiers. Product codes, ticket numbers and serials pasted from CJK documents frequently arrive full-width. Normalising them is the first step before validation.
• Punctuation. Full-width commas, colons and parentheses (，：（）) are visually distinct from ASCII and break CSV parsing, JSON syntax and command-line arguments.
• Data migration. Text exported from older CJK systems may be entirely full-width, including digits in numeric columns.

What is deliberately left alone

Only the ranges that have a genuine half-width equivalent are converted. CJK ideographs, kana, hangul, and the CJK punctuation that has no ASCII counterpart are preserved as-is. Converting 漢字 to anything would be a transliteration, not a width change, and that is a different operation with a different tool.

Full-width punctuation that does have an ASCII equivalent — ，。：；！？（）“” — is not automatically converted by the width mapping, because the mapping is defined for characters whose visual form is genuinely the Latin one at double width, not for typographic punctuation. If you need that, convert the punctuation explicitly; treating 。 as a full stop is a language decision, not an encoding one.

Normalisation and width

Unicode normalisation form NFKC includes width folding: it maps full-width ASCII forms to their half-width equivalents as part of compatibility composition. That means a single normalize('NFKC') call will do most of what this tool does, plus other compatibility mappings (ligatures, superscripts, circled letters). It is a convenient shortcut if you want aggressive folding, and a hazard if you wanted to preserve typography — NFKC is lossy, and it will also turn ㈱ into (株) and ㎡ into m2.

This tool is the explicit version: it converts width and nothing else. That makes it the right choice when you want to normalise an identifier without altering anything else in the string.

Frequently asked questions

Go deeper

Longer explanations of the problems this tool solves:

Bytes, hex and entities: the same text in four notations

Sources

• Unicode Standard, Halfwidth and Fullwidth Forms block (U+FF00–U+FFEF), including the full-width ASCII range U+FF01–U+FF5E.
• Unicode Standard, CJK Symbols and Punctuation, for the ideographic space U+3000.