Korean Byte Calculator

How UTF-8 and EUC-KR count bytes

The number of characters and the number of bytes are two different things, and the gap between them is entirely decided by the encoding. In UTF-8, the web standard, each complete Hangul syllable such as the ones spelling 'annyeong' takes 3 bytes, while plain ASCII characters (English letters, digits, and common punctuation like . , ! ?) take 1 byte, and a line break usually counts as 1 byte. In EUC-KR, an older Korean encoding still used by some legacy systems, each Hangul syllable takes 2 bytes while ASCII stays at 1 byte. So the byte total is never just the character count multiplied by a single number; it is the sum of each character's own byte width under the chosen encoding. This tool applies both rules to the exact same text at once so you can read the two totals side by side instead of guessing.

A worked example so the numbers are concrete

Suppose you type a 10-character string made of 5 Hangul syllables and 5 English letters, for example 'Hello안녕하세요'. Under UTF-8 the 5 English letters are 5 bytes and the 5 Hangul syllables are 5 times 3, which is 15 bytes, for a total of 20 bytes. Under EUC-KR the same 5 English letters are still 5 bytes but the 5 Hangul syllables are 5 times 2, which is 10 bytes, for a total of 15 bytes. Same visible text, same 10 characters, yet 20 bytes versus 15 bytes depending on the encoding. This is exactly why a message that fits a limit on one system silently overflows it on another, and why reading both totals matters before you hit save or send.

Where byte limits actually bite

• Database column widths: a field declared as VARCHAR(30) may mean 30 bytes rather than 30 characters, so 10 Hangul syllables in UTF-8 already consume all 30 bytes and the eleventh character gets truncated or rejected.
• Legacy Korean forms and message boards: many were built on EUC-KR, so their input limits are phrased as bytes on a '1 Hangul = 2 bytes' basis, and pasting text validated only for character count can fail server-side.
• SMS and marketing copy: mobile carriers bill by byte, and a single SMS is capped at 90 bytes on the EUC-KR basis (about 45 Hangul or 90 ASCII characters); one character over turns it into a longer, more expensive message.
• Fixed-width file exports and APIs: banking, government, and EDI formats often specify byte offsets, so knowing the true byte length prevents fields from shifting out of alignment.
• Bio and title fields with hard caps: profile names, product titles, and metadata fields sometimes count bytes internally even when the UI shows a character counter.

SMS, LMS, and what the 90-byte line really means

For Korean mobile messaging the practical dividing line is 90 bytes measured on the EUC-KR basis. Within that budget you get roughly 45 Hangul syllables, or 90 English letters and digits, or any mix that stays under 90 bytes; cross it and the message is promoted to a long message (LMS), which is billed differently and rendered as a separate message type. Because carriers historically standardized on the 2-byte-per-Hangul convention, the byte figure that decides single-versus-long is the EUC-KR number, not the UTF-8 number, even though your phone and apps store the text as UTF-8 internally. If you are writing promotional copy or a template that must stay a single SMS, watch the EUC-KR total here and keep it at or under 90, then confirm the exact threshold with your sending provider since some platforms reserve a few bytes for headers.

Common mistakes and misconceptions

• Assuming 'characters equals bytes': counting characters and assuming the byte limit is the same number is the single most frequent cause of truncated Korean text.
• Assuming every Hangul syllable is always 3 bytes: that is only true for UTF-8; on an EUC-KR system it is 2, so applying the wrong constant makes you either waste space or overflow.
• Forgetting that spaces, line breaks, and punctuation also cost bytes: a message that looks like it fits can go over once the newlines and spaces are counted.
• Trusting a UI character counter for a byte limit: a form may display '20/30 characters' while the server silently enforces 30 bytes, so both numbers need checking.
• Treating emoji and rare symbols as one 'unit': a single emoji can be 4 bytes in UTF-8 and often cannot be represented in EUC-KR at all.

Cautions and limits of this tool

• The EUC-KR figure is an approximation based on the standard completed-syllable set; archaic Hangul jamo combinations, some old-style characters, and certain symbols may store differently or not at all under real EUC-KR.
• Emoji and many special characters have no EUC-KR representation, so on a genuine EUC-KR system they may be dropped, replaced, or cause an error rather than simply costing bytes.
• Always confirm which encoding a specific limit refers to; a posting that says 'max 100 bytes' is meaningless until you know whether it means UTF-8 or EUC-KR.
• Byte width can also vary with normalization form (for example precomposed versus decomposed Hangul), which some systems handle differently than the simple per-syllable count shown here.

Your text stays in your browser

Everything this calculator does runs locally in your browser using JavaScript. The text you paste is measured on your own device and is never uploaded, logged, or stored on any server, so you can safely check the byte length of drafts, private messages, or internal copy without it leaving your machine. Because there is no round trip to a server, the counts also update instantly as you type, which makes it easy to trim a message toward a limit one character at a time.