Tool

Korean characters and bytes

Dropping spaces and counting UTF-8 or EUC-KR bytes are different questions. Korean ‘word count’ is not the same as spaces, so this page does not invent one.

Counts run in the browser. The EUC-KR index loads only on this page. The paste is not sent to GearDel.

What each number is

Code points: the JavaScript string iterator, so one Hangul syllable is one, and a supplementary-plane character is one.

Without spaces: code points that do not match Unicode whitespace.

Graphemes: Intl.Segmenter when the browser has it. Combining marks can make this differ from code points. If Segmenter is missing, the field stays blank.

Lines: splits on CR, LF, or CRLF. An empty box is 0 lines.

UTF-8 bytes: TextEncoder.

EUC-KR bytes: the WHATWG euc-kr index (the web label euc-kr, which matches windows-949). ASCII is one byte; indexed Hangul and Hanja are two. Emoji and other missing code points are counted separately and are not given a guessed byte length.

Whitespace-separated fields: splits on Unicode whitespace after trim. That is not a Korean word count.

What this page does not do

It does not count ‘words’ in a linguistic sense. Korean spacing is not a tokenizer.
It does not implement EUC-JP, Shift_JIS, or GBK.
It stops at 200,000 code points.

Questions

Why is UTF-8 larger than the character count?

Hangul syllables are three UTF-8 bytes each. ASCII is one. The byte column is TextEncoder, not a character count.

Why does EUC-KR refuse an emoji?

The index has no pointer for that code point. The page reports how many characters could not be encoded instead of inventing a length.

Is this the same as MS Word’s count?

No. Word uses its own rules for spaces and lines. This page documents the iterators above.