모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
텍스트 영역에 붙여 넣거나 입력하면 5개 수치가 실시간으로 갱신됩니다. 총 문자 수(바이트가 아닌 Unicode 코드 포인트 단위), 공백을 제외한 문자 수, 단어 수(공백 구분으로 이어진 덩어리), 줄 수(`\r\n`·`\r`·`\n` 중 어느 것이든 구분자로 셈), 바이트 수(UTF-8 인코드 후 길이)입니다. 모두 즉시 반영 — 제출 버튼도 서버 왕복도 없습니다.
길이가 중요한 상황에서 사용하세요. 메타 디스크립션(Google은 약 155~160자에서 잘림), Twitter 글(이모지 인식 280자), SMS(GSM-7로 160자, UCS-2로 세그먼트당 70자), YouTube 댓글(10000자), 엄격한 `VARCHAR(255)` 제한이 있는 데이터베이스 컬럼 같은 경우입니다. 바이트 수 표시는 "글자 수" 상한이 실제로는 UTF-8 바이트 상한인 경우에 특히 유용합니다. 옛 MySQL 컬럼이나 일부 API 쿼터에서 자주 보입니다. 한국어·일본어 텍스트는 UTF-8에서 글자당 3바이트로 부풀기 때문에 한국어 100자 단락은 약 300바이트입니다.
Open-source web utilities — JSON, Base64, UUID, regex, and more. Everything runs in your browser, no upload required, no signup.
Characters: 134 Characters (no WS): 116 Words: 21 Lines: 1 Bytes (UTF-8): 134
134자이므로 Google의 소프트 상한 약 160자에 들어가며 페이지 제목 접두사용 여유도 있습니다. 글자 수와 바이트 수가 같은 이유는 텍스트가 모두 ASCII라 각 코드 포인트가 1바이트에 들어가기 때문입니다. 같은 문장을 한국어로 옮기면 바이트 수는 대략 3배로 부풀고 글자 수는 줄어듭니다.
안녕하세요, 오늘 날씨가 참 좋네요.
Characters: 20 Characters (no WS): 18 Words: 4 Lines: 1 Bytes (UTF-8): 53
가시 글자 20개, UTF-8 바이트 53(약 2.65배 팽창). 각 한글 음절(`안`·`녕`·`하` 등)은 UTF-8에서 3바이트, 구두점과 공백은 1바이트씩입니다. `VARCHAR(20)` 컬럼이 이 문자열을 받을지는 데이터베이스가 글자 수(PostgreSQL)로 재는지 바이트 수(옛 MySQL의 latin1, GBK 계열 인코딩)로 재는지에 달렸습니다. 반드시 확인하세요.
👨👩👧 안녕! café 🌸
Characters: 18 Characters (no WS): 14 Words: 3 Bytes (UTF-8): 45
가족 이모지 `👨👩👧`는 **7개 코드 포인트**(인물 이모지 3개 + 폭 0 결합자 2개, 피부톤 없는 기본 형태)이지만 표시는 글리프 하나입니다. `café`의 `é`는 사전 합성이면 1 코드 포인트, `e` + 결합용 어큐트 악센트면 2 코드 포인트입니다. `[...text].length`는 코드 포인트 수, `text.length`는 UTF-16 코드 단위 수(가족 이모지만으로 16)를 돌려줍니다. Twitter·Discord·현대 다수의 시스템은 가족 이모지를 1로 세는 그래핌 클러스터 카운트를 사용하며, 이 도구의 어떤 수치와도 일치하지 않습니다.
UTF-8은 ASCII(U+0000~U+007F)에 1바이트, 다음 약 1900자(라틴 확장·그리스·키릴·히브리·아랍 등)에 2바이트, BMP의 나머지(한국어·중국어·일본어·기타 다수 문자)에 3바이트, 보조 평면(대다수 이모지·고대 문자·드문 CJK)에 4바이트를 사용합니다. 순수 ASCII 영문은 글자당 1바이트, 한국어는 글자당 3바이트, 이모지가 가득한 문장은 가시 글리프당 4바이트 + ZWJ 시퀀스 오버헤드가 더해집니다. 저장 계층과 다수의 API가 재는 것이 이 바이트 수입니다.
이 카운터는 Unicode *코드 포인트 수*를 잽니다. 가시 *그래핌 수*가 아닙니다. `👨👩👧👦`(4인 가족) 같은 이모지 글리프 하나는 실제로는 7 코드 포인트(인물 이모지 4 + 폭 0 결합자 3)입니다. 사용자가 "한 글자"로 보는 그래핌 클러스터를 얻으려면 `Intl.Segmenter` API(또는 `grapheme-splitter` 같은 라이브러리)가 필요합니다. Twitter·Discord·현대 SNS는 그래핌을 세므로 코드 포인트와 맞지 않습니다. 그래핌 수가 필요하면 Twitter 초안 칸에 붙여 넣어 실제 숫자를 확인하거나, DevTools에서 `Array.from(new Intl.Segmenter("en", { granularity: "grapheme" }).segment(text)).length`를 실행하세요.
세지 않습니다. 이 카운터는 공백으로 분리하므로 공백 없는 일본어 문장은 길이에 관계없이 1 단어로 세어집니다. 진짜 단어 분할에는 형태소 분석기(일본어는 kuromoji, 중국어는 jieba, 한국어는 KoNLPy)가 필요하며 언어 의존적입니다. CJK 콘텐츠에서는 글자 수가 길이의 의미 있는 척도이며, 출판사(NHK·아사히·요미우리)가 전통적으로 번역료를 책정해 온 단위이자 Twitter가 CJK 게시물을 무겁게 다루는 방식(글자 1 = 2글자분으로 280자 한도에 산입, 실효 상한은 CJK 140자)과도 일치합니다.
**SEO 메타 디스크립션**: 약 155~160자에서 Google이 잘라냅니다. **HTML `<title>`**: 데스크톱 약 60, 모바일 약 50. **Twitter·X**: 280자(CJK는 2배 가중되어 실효 140). **Bluesky**: 300자. **Mastodon**: 기본 500자(인스턴스별 설정 가능). **SMS**: GSM-7로 160자, UCS-2(Unicode)로 세그먼트당 70자. 이를 넘으면 다중 세그먼트로 나뉘어 각각 따로 과금됩니다. **YouTube 댓글**: 10000자. **GitHub 커밋 메시지**: 엄격한 상한은 없지만 50·72 관례(제목·본문 줄바꿈). **데이터베이스 VARCHAR**: 상황 의존 — MySQL의 `VARCHAR(255)`는 바이트(옛 설정)냐 글자(현대 utf8mb4)냐로 다르므로 컬럼 문자 집합을 확인하세요.
끝의 `\n`은 카운트를 1 증가시킵니다. 줄바꿈 뒤에 빈 줄이 생기기 때문입니다. `hello\nworld`는 2줄이고, `hello\nworld\n`도 대부분의 에디터에서는 2줄이지만 이 도구가 채택한 "구분자로 나눠 세는" 방식에서는 3줄입니다. 분할이 `["hello", "world", ""]`의 3 요소를 돌려주기 때문입니다. POSIX 텍스트 파일은 관례적으로 `\n`으로 끝나지만, "내용 있는 줄 수"를 세고 싶다면 `wc -l`(끝의 줄바꿈을 명시 카운트)과 같은 숫자를 원할 것입니다. 하류 소비자의 관례에 맞춰 고르세요.
이 도구로는 안 됩니다 — 토큰화는 모델 고유입니다. OpenAI는 tiktoken(BPE), Anthropic Claude는 다른 BPE 변종, Google Gemini와 Llama는 각자 자체 토크나이저를 가집니다. 경험칙은 1 토큰 ≈ 영어 4글자 ≈ CJK 0.5글자이므로 이 도구의 글자 수를 4로 나누면 영어 추정이 됩니다. 정확히 세고 싶다면 OpenAI의 `tiktoken` 라이브러리를 로컬에서 돌리거나 플레이그라운드를 사용하세요. Anthropic이면 `count_tokens` 엔드포인트를 쓸 수 있습니다.
"이 텍스트가 얼마나 긴가"는 보기보다 다층적인 문제입니다. 같은 문자열에 대한 합리적 답이 5가지 있습니다. **바이트 수**는 저장 척도로 UTF-8 인코드 후 길이입니다(`wc -c`가 돌려주는 값). **코드 단위**는 다수 문자열 타입의 메모리 표현 척도로, JavaScript와 Java의 UTF-16에서는 `"hello".length`가 5이지만 `"𐀀".length`는 2입니다(보조 평면 1 글자가 2 코드 단위를 차지). **코드 포인트 수**는 Unicode 추상 척도로 JavaScript의 `[...str].length`나 `wc -m`이 돌려주는 값입니다. **그래핌 수**는 사용자에게 보이는 척도이며 `👨👩👧👦`는 그래핌 1이지만 코드 포인트 7. `Intl.Segmenter`가 이 수를 제공합니다. **단어 수**는 라틴 계열에서는 공백 구분, CJK에서는 형태소 구분이므로 어떤 도구도 모든 언어에서 옳게 셀 수 없습니다.
이 차이는 "글자 수 제한"이 부과되는 모든 자리에서 의미를 가집니다. 280자 Twitter 글은 그래핌이지 코드 포인트나 바이트가 아닙니다. MySQL의 255자 `VARCHAR`는 컬럼이 `latin1`이면 바이트, `utf8mb4`이면 글자입니다. SMS 제한은 세그먼트당 GSM-7 160 셉테트 또는 UCS-2 70 코드 단위입니다. 브라우저는 메타 디스크립션을 글자 수가 아닌 픽셀 폭으로 시각적으로 잘라내므로 `Wide W`만 든 문자열은 `iiiiii`보다 일찍 잘립니다. 하류 소비자에게 맞는 척도를 고르는 편이 "보기 좋은" 둥근 숫자를 고르는 것보다 유용합니다.
인접한 3가지 개념이 있습니다. **정규화**(NFC vs NFD)는 코드 포인트 수에 영향을 줍니다. `é`는 NFC에서 1 코드 포인트, NFD에서 2 코드 포인트이므로 비교 전 정규화가 중요합니다. **양방향(bidi) 텍스트**는 왼쪽에서 오른쪽과 오른쪽에서 왼쪽 스크립트를 섞습니다. 카운트는 그대로지만 시각적 길이는 직관에 반합니다. **폭**(고정폭 폰트일 때)은 East Asian Width에 의존합니다. 전각 한국어 글자는 터미널에서 2열, 반각 라틴 글자는 1열을 차지합니다. `wcwidth` 계열 함수가 이를 표현합니다.
camelCase / PascalCase / snake_case / kebab-case / CONSTANT_CASE / Title Case를 서로 변환합니다.
단어/문장/단락 단위로 더미 텍스트를 생성합니다. 고전적인 "Lorem ipsum…" 시작 옵션 지원.
한글을 국립국어원 로마자 표기법 또는 매큔–라이샤워식으로 변환합니다. 기본 자음 동화 규칙을 반영합니다.
한국 주소를 영문 표기로 변환합니다. 해외 배송, 비자 신청, 각종 폼 작성에 유용합니다. 시/도 영문명 테이블과 도로명·구의 자동 로마자 변환을 내장했습니다.
