글자 수와 바이트가 다른 이유: 한글·이모지·줄바꿈 확인법

숫자가 다르면 먼저 어떤 기준인지 확인하세요

같은 문장을 넣었는데 제출 화면과 계산기의 값이 다르다면, 문장을 줄이기 전에 집계 기준부터 구분하세요. 이 가이드는 짧은 시험 문자열로 차이를 좁히는 순서입니다. 도구의 기본 ‘글자 수’는 UTF-16 코드 단위, 코드 포인트는 문자 값의 개수, ‘화면상 글자’는 그래핌 클러스터, 바이트는 UTF-8 인코딩 크기를 뜻합니다.

아래 표에서 짧은 입력의 기대값을 확인하고, 줄바꿈·보이지 않는 문자·정규화 순으로 살펴보세요. 실제 제출처는 URL이나 이모지에 별도 규칙을 적용할 수 있으므로 이 네 값 중 하나와 반드시 일치하는 것은 아닙니다.

짧은 예제로 집계 방식을 구별합니다

영문 A는 네 기준 모두 1입니다. 가족 이모지는 UTF-16 11, 코드 포인트 7, 그래핌 1, UTF-8 25로 갈립니다. 아래 열 가지 입력 표에서 한글·공백·줄바꿈까지 같은 순서로 비교할 수 있습니다.

가족 이모지는 사람을 나타내는 네 코드 포인트와 보이지 않는 연결 문자 세 개로 구성됩니다. 브라우저가 이를 한 이모지로 묶어 그리면 화면상 글자는 하나여도 코드 포인트는 일곱, UTF-16 단위는 열하나입니다. 폰트나 시스템이 해당 조합을 지원하지 않으면 여러 기호로 보일 수도 있습니다.

표의 문자를 하나씩 글자 수 계산기에 붙여넣기

이 표는 현재 브라우저의 그래핌 분할 지원을 전제로 검산했습니다. 도구의 설명처럼 분할 기능이 없는 환경에서는 화면상 글자 표시가 코드 포인트 개수로 대체될 수 있으므로, 그 환경의 결과를 실제 글자 모양과 동일하다고 단정하면 안 됩니다.

같은 가라도 저장 방식이 다를 수 있습니다

완성형 ‘가’는 U+AC00 한 코드 포인트입니다. 반면 초성 ‘ᄀ’(U+1100)과 중성 ‘ᅡ’(U+1161)를 결합한 문자열은 두 코드 포인트이며 UTF-8로 6바이트입니다. 둘 다 비슷한 한 글자로 보일 수 있지만 저장된 단위 수는 다릅니다.

이 사이트는 한글·결합 문자를 NFC 등의 유니코드 정규화로 다시 쓰지 않고 받은 내용을 셉니다. 다른 서비스가 정규화 후 제한을 적용하면 같은 표시 문장도 숫자가 달라질 수 있습니다. 문서를 복사·붙여넣은 뒤 예상과 다르면 보이지 않는 공백과 결합 문자도 확인할 대상입니다.

공백처럼 보이는 문자도 제거 결과가 다릅니다

다음 세 입력은 모두 A와 B 사이에 문자 하나가 있습니다. U+0020은 일반 공백, U+00A0은 줄바꿈 방지 공백, U+200B는 제로폭 공백입니다. 화면에 거의 표시되지 않아도 저장된 값은 다릅니다.

앞의 두 공백은 이 도구의 공백 제외 계산에서 빠지지만 제로폭 공백은 남습니다. ‘공백 제외’인데도 두 글자가 되지 않는다면 이 차이를 의심할 수 있습니다. 다만 보이지 않는 문자를 전부 지우면 가족 이모지를 연결하는 문자까지 손상할 수 있으므로, 원문을 보관하고 확인된 문자만 수정하세요.

파일의 줄바꿈과 입력창의 줄바꿈은 별도로 봅니다

CR과 LF가 이어진 줄바꿈은 그래핌 분할에서 하나로 묶이지만 코드 단위와 바이트에서는 둘입니다. 줄바꿈도 그래핌에 포함되므로 여기서 ‘그래핌 3개’는 눈에 보이는 글자가 세 개라는 뜻은 아닙니다.

브라우저의 textarea 값은 줄바꿈을 LF로 정규화합니다. 따라서 CRLF가 들어 있는 원문을 이 도구에 붙여넣으면 파일 원문 표의 4바이트가 아니라 3바이트가 나올 수 있습니다. 이 계산기는 파일 업로드 분석기가 아니므로 원본 파일의 바이트 크기나 제출 서버의 저장 형식까지 재현하지 않습니다.

줄 수는 내용이 있는 줄만 세고 문단은 빈 줄로 나눈 블록을 셉니다. 화면 폭 때문에 자동으로 접힌 줄은 실제 줄바꿈 문자와 다릅니다.

한도에 맞추기 전에 원문과 기준을 보관하세요

먼저 제출처가 공백을 포함하는지, 바이트 제한이면 어떤 인코딩을 쓰는지 확인합니다. 이 도구는 UTF-8을 사용하며 다른 인코딩의 크기를 대신하지 않습니다. 한도 기능은 초과량만 안내하고 입력한 글을 자동으로 자르지 않습니다.

글을 줄일 때는 원문을 별도로 보관하세요. 코드 단위로 잘라낸 문자열은 이모지 중간이 끊길 수 있으므로 실제 제출 화면에서 내용과 카운터를 다시 확인해야 합니다. 민감한 원문으로 시험하기 전에 아래 짧은 예제로 기준 차이를 먼저 확인하세요.

열 가지 입력으로 결과를 재현하는 방법

2026년 9월 26일 아래 입력을 실제 도구의 집계 함수로 검산했습니다. 따옴표를 제외한 원문을 사용하고, 표의 순서는 UTF-16·코드 포인트·그래핌·UTF-8 바이트입니다. 그래핌은 Intl.Segmenter 지원 환경을 전제로 합니다. 다른 서비스와의 실측 비교가 아닌 이 사이트 집계 규칙의 재현 자료입니다.

완성형·분해형 한글과 이모지는 표의 문자를 직접 붙여넣을 수 있습니다. 보이지 않는 문자와 CRLF 원문까지 정확히 재현하려면 아래 JavaScript를 브라우저 개발자 도구 콘솔에서 실행하세요. 개인 문서나 네트워크를 읽지 않고 명시된 시험 문자열만 계산합니다.

const samples = ["A", "\uAC00", "\u1100\u1161", "👍🏽", "👨‍👩‍👧‍👦",
  "A B", "A\u00A0B", "A\u200BB", "A\nB", "A\r\nB"];
const segmenter = new Intl.Segmenter("ko", { granularity: "grapheme" });
console.table(samples.map(text => ({
  input: JSON.stringify(text), utf16: text.length,
  codePoints: [...text].length,
  graphemes: [...segmenter.segment(text)].length,
  utf8: new TextEncoder().encode(text).length
})));

CRLF 원문 검사는 콘솔에서 하고, 입력창 검사는 A를 입력한 뒤 Enter를 누르고 B를 입력해 확인하세요. 두 결과를 구분하면 원본 파일과 입력창 카운터의 차이를 글자 수 오류로 오해하지 않을 수 있습니다.

붙여넣기 전후 확인 순서

1. 제출처가 글자·바이트 중 무엇을 제한하는지 읽습니다.
2. 도구의 UTF-16·코드 포인트·화면상 글자 값을 비교합니다.
3. 공백·줄바꿈·이모지·결합 문자가 있는지 확인합니다.
4. 원문을 보관한 뒤 필요한 길이로 편집합니다.
5. 실제 제출 화면에 붙여넣고 표시와 길이를 마지막으로 확인합니다.

바이트를 KB·KiB로 바꿀 때의 차이는 데이터 용량 단위 가이드에서 확인하세요.