Text Runs locally Ready to use Built-in examples No tracking

Full-width / Half-width Converter

Turn full-width characters like ABC123 into ABC123, or do the reverse. Text copied out of PDFs and Word documents often carries full-width digits that fail form validation; this tool fixes that. Chinese-only punctuation is left as is.

Full-width and half-width forms are a residue of CJK input: text copied out of a PDF, a Word file or some admin editors carries full-width digits and letters (ABC123) that fail form validation once pasted in, with phone numbers, ID numbers and order codes the usual casualties. This tool compresses full-width ASCII back to half-width, or expands it the other way for typographic alignment.

The rule underneath is small: full-width ASCII (U+FF01–FF5E) and half-width ASCII (U+0021–7E) stand exactly 0xFEE0 apart, and the full-width space (U+3000) maps to the ordinary space. CJK-specific punctuation — the ideographic full stop, the enumeration comma, the curly quotes — falls outside that range and passes through unchanged, so commas and brackets visibly changing while a full stop does not is expected, and means that full stop was CJK punctuation all along.

How to use

  1. Paste the text to convert.
  2. Choose the direction: full-width to half-width, or the reverse.
  3. Read the converted result.
  4. Check the note on CJK punctuation, which is deliberately left untouched.

How it works

Basic usage

Pick a direction, paste content into the box, and the result updates instantly; the statistics below tell you how many characters changed and how many stayed untouched. The copy button grabs the complete converted text, ready to paste back into a form or document.

The width-conversion rules

Only two rules: fullwidth ASCII (U+FF01–FF5E) and halfwidth ASCII (U+0021–7E) differ by exactly 0xFEE0 per character, and the fullwidth space U+3000 maps to the halfwidth space U+0020. So "fullwidth → halfwidth" also compresses punctuation inside that block — ,!?:;() — while Chinese-only punctuation like 。、、“”《》【】 sits outside the block and stays untouched.

How it divides work with the punctuation converter

The two tools solve different problems: this one handles character width (fullwidth letters, digits and the fullwidth space); the punctuation converter handles Chinese/English punctuation habits (。→. ,→, including punctuation outside the block). Width only — keep Chinese punctuation: use this tool. Convert all Chinese punctuation to English style: use the punctuation tool.

Method: fullwidth ASCII (U+FF01–U+FF5E) and halfwidth ASCII (U+0021–U+007E) map to each other with an offset of 0xFEE0, and U+3000 ↔ U+0020 for the space. CJK characters, kana, and fullwidth punctuation outside the fullwidth ASCII block stay exactly as they are.

Code example

JavaScript Converting between halfwidth and fullwidth

// Fullwidth to halfwidth
const toHalf = (s) => s
  .replace(/[\uFF01-\uFF5E]/g, (c) => String.fromCharCode(c.charCodeAt(0) - 0xFEE0))
  .replace(/\u3000/g, ' ');

// Halfwidth to fullwidth
const toFull = (s) => s
  .replace(/[\u0021-\u007E]/g, (c) => String.fromCharCode(c.charCodeAt(0) + 0xFEE0))
  .replace(/ /g, '\u3000');

toHalf('ABC123'); // 'ABC123'
toFull('ABC123');      // 'ABC123'

Shell Cleaning up fullwidth characters pasted from forms

# First list the fullwidth alphanumerics in the file (to gauge the scope)
grep -nP "[\x{FF01}-\x{FF5E}]" data.txt | head

# Batch-convert with Python (no manual code-point arithmetic)
python3 - <<'PY' > fixed.txt
s = open('data.txt', encoding='utf-8').read()
print(''.join(chr(ord(c) - 0xFEE0) if 0xFF01 <= ord(c) <= 0xFF5E else c for c in s), end='')
PY

FAQ

What actually distinguishes fullwidth from halfwidth?

The width they occupy in fonts: halfwidth takes 1 unit (ABC, 123), fullwidth takes 2 (ABC, 123) — so in monospace fonts fullwidth looks twice as wide. Punctuation typed in a Chinese IME and digits copied from PDFs are often fullwidth.

Why did the comma become halfwidth too after converting?

Because the fullwidth comma (,= U+FF0C) falls inside the fullwidth ASCII block U+FF01–FF5E, so width normalization takes it along. That's an inevitable consequence of width normalization and matches most tools. If you only want alphanumerics converted while keeping Chinese punctuation style, replace manually afterwards, or use the punctuation converter for punctuation alone.

The period is still fullwidth after converting — did it fail?

No, that's correct behavior. The Chinese period 。 is U+3002, outside the fullwidth ASCII block with no halfwidth-width counterpart, so width conversion leaves it alone. What does convert: ,!?:;() within U+FF01–FF5E, plus the fullwidth space.

Do regular spaces change during fullwidth conversion?

Yes. The halfwidth space (U+0020) maps to the fullwidth space (U+3000), and converting it along is the convention. If you want characters fullwidth but spaces kept halfwidth, convert first then replace fullwidth spaces back in an editor — the display difference is obvious.

A form rejects my phone number or ID — what now?

Almost certainly fullwidth digits: validation like ^\d+$ doesn't match fullwidth 123, which aren't digit characters. Paste here, run fullwidth → halfwidth, and paste back; also check whether fullwidth spaces snuck in at the ends.

Are Chinese characters converted?

No. Han characters naturally occupy two width units and have no halfwidth form, so they're out of scope. Kana, Hangul and symbols (℃, © and friends) also stay put — this tool touches only the fullwidth ASCII block and the fullwidth space.

Why does the fullwidth space look so wide and break validation?

U+3000 spans two character widths in monospace fonts, looking like indentation — but it isn't a normal space, and plenty of checks break on it: trim mismatches, URL parameters, JSON keys, exact-match rules. Run fullwidth → halfwidth to expose where it hides; the "converted characters" count confirms it.

Will my text be left on a server?

No. Conversion happens in the browser; input is neither uploaded nor written to localStorage. With no history section, contracts and name lists leave no trace either.