Full/Half Width Converter

Convert between full-width and half-width characters

Full-width characters occupy the width of one Han character; half-width ones occupy half that. Chinese and Japanese input methods produce full-width letters and digits easily by accident, and ABC123 merely looks wider while being an entirely different string from ABC123 — hence the lookup that returns nothing and the validation that refuses to pass. This tool converts between the two forms in either direction, live, inside your browser.

How to use it

  1. Choose a direction with the two buttons at the top: Half-width → Full-width, or Full-width → Half-width. The first is selected by default.
  2. Paste into the Input box on the left; the Output box updates as you type, with nothing to confirm. Switching direction keeps whatever you have already typed, so you can flip straight over to see the reverse result.
  3. Take the result with Copy at the bottom right. Clear, on the left, empties the input box.

When it comes in handy

Repairing reference numbers pasted from Excel or Word

Invoice numbers, tax IDs and phone numbers stored full-width will not match in a VLOOKUP, get rejected on upload, and break outbound SMS. Running the whole column through Full-width → Half-width is faster than retyping, and unlike retyping it cannot introduce a wrong digit.

Cleaning user input before it reaches a database or API

Addresses and URLs submitted through a form often carry a full-width @ or . that is almost invisible on screen. Normalising a sample here before you write the validation rule tells you whether the rule is too strict or the data really is malformed.

Making digits full-width for typographic alignment

In official documents, certificates and vertically set text, half-width digits wedged between Han characters look uneven. Converting them to full-width gives every character the same advance width, and avoids digits lying on their side in vertical typesetting.

Limits and behavior

  • Half-width → Full-width covers the visible ASCII range ! through ~ — letters, digits and every ASCII punctuation mark — and additionally turns the ASCII space into the ideographic space  . Tabs and line breaks are left as they are, neither converted nor consumed.
  • Full-width → Half-width reads the block from ! to ~ and turns the ideographic space back into an ASCII space. The catch is that this block contains punctuation Chinese uses constantly — ,, (, ), :, ? — so a whole Chinese passage comes back with those converted to ,, () and :. Meanwhile 。, 、, 「」 and 《》 live in a different block, stay outside the mapping and survive unchanged, which is why converted Chinese prose ends up looking inconsistent.
  • Half-width katakana such as アイウ and full-width currency symbols like ¥ and £ are not in the mapping and are untouched in both directions; the non-breaking space U+00A0 is likewise not treated as an ASCII space.
  • Do not send URLs, code or JSON through Half-width → Full-width: https://a.com becomes https://a.com, which looks similar and is no longer clickable or executable.
  • There is no file upload — the tool works on whatever you paste into the box. Conversion is performed by JavaScript in this tab and your text is not sent anywhere. The page does still load third-party resources such as advertising, which is unrelated to the contents of the input box.

Frequently asked questions

Why did my Chinese comma turn into an ASCII comma?

The full-width comma , sits inside the very block this direction converts, and its half-width counterpart happens to be ,. Nothing in the character itself distinguishes "a full-width ASCII comma I want narrowed" from "the Chinese comma I want kept". If your goal is only to fix letters and digits, isolate those fields before converting rather than pasting a whole prose passage in.

Then why did the full stop and quotation marks survive?

The Chinese 。 and 「」 do not belong to the same block as full-width letters and digits, and they have no one-to-one half-width equivalent, so they are simply not in the table. That mismatch is what makes converted Chinese prose look uneven.

Is the conversion guaranteed to round-trip?

For letters, digits and ASCII punctuation, yes — that range is a strict one-to-one mapping in both directions. The case that surprises people is whitespace: a passage mixing ideographic and ASCII spaces comes back with all of them collapsed into a single kind, so the count is preserved but the widths are not what you started with.

Can I convert only the digits and leave letters alone?

Not currently — the interface offers a direction and nothing else, with no filter by character class. In practice, copy out just the lines that need fixing, convert those, and paste them back. To touch only the digits across a whole document, a regular-expression replace in your editor is the more precise instrument.