텍스트 ↔ UTF-8 16진수 변환기

한은 ED 95 9C: 글자가 UTF-8에서 차지하는 바이트

UTF-8 16진수 변환은 글자를 컴퓨터가 실제로 저장하는 UTF-8 바이트로 바꾸고, 바이트 하나를 00~FF 두 자리 16진수로 적는 일입니다. 한글 '한'은 유니코드 번호(코드 포인트)가 U+D55C이고 UTF-8로는 ED 95 9C 세 바이트가 됩니다. 영문 A는 41 한 바이트, 이모지 😀는 F0 9F 98 80 네 바이트입니다. 반대로 로그나 프로그램에서 받은 ED 95 9C를 넣으면 다시 '한'으로 되돌릴 수 있습니다.

위 변환기는 텍스트 칸과 16진수 칸을 모두 고칠 수 있습니다. 고친 쪽이 기준이 되고, 가운데 띠에 글자마다 그 글자의 바이트를 자막처럼 붙여 보여 줍니다. 띠의 바이트 칸 아래 색은 1·2·3·4바이트를 나타내고, 글자를 누르면 비트 돋보기가 코드 포인트의 비트가 UTF-8 바이트 어느 자리에 들어가는지 그립니다. 16진수는 공백 구분, 붙여 쓰기, 0x 배열, \x 이스케이프, % 인코딩 가운데 하나로 적고, 붙여 넣을 때는 이 다섯 가지를 모두 읽습니다.

UTF-8 바이트를 직접 봐야 하는 상황

• 한글이 깨져서 원래 인코딩을 알아내야 할 때: UTF-8 한글은 대개 EA~ED로 시작하는 3바이트이고, EUC-KR(CP949) 한글은 2바이트입니다. 깨진 글을 만든 바이트를 16진수로 넣으면 UTF-8로 읽히는지, 읽히지 않으면 EUC-KR로는 무엇인지 함께 보여 줍니다.
• 로그에 \xED\x95\x9C 같은 값이 찍혔을 때: Python은 bytes 값을 화면에 보일 때 ASCII 밖의 바이트를 b'\xed\x95\x9c'처럼 \x 이스케이프로 적습니다. 이 값을 그대로 16진수 칸에 붙여 넣으면 감싼 b'…'와 그대로 적힌 영문까지 읽어 원래 글로 되돌립니다.
• DB 저장 오류가 바이트 수 때문일 때: MySQL의 utf8mb3(예전 이름 utf8)은 문자당 최대 3바이트라서 4바이트 글자인 이모지를 저장하지 못합니다. 이때 나오는 오류 1366 메시지에는 문제 값이 Incorrect string value: '\xF0\x9F\x98\x80'처럼 바이트로 적힙니다. 이 부분을 변환기에 넣으면 😀 한 글자가 4바이트라서 막혔다는 것을 바로 알 수 있습니다.
• 눈으로는 같은데 비교·검색이 어긋날 때: 줄바꿈 없는 공백(C2 A0), 폭 없는 공백(E2 80 8B), 파일 맨 앞의 BOM(EF BB BF)은 화면에 보이지 않지만 바이트는 다릅니다. 띠에서는 NBSP·ZWSP·BOM 같은 이름표로 표시됩니다.
• 한글 자모가 풀어진 이름을 다룰 때: 맥의 HFS Plus(Mac OS 확장) 볼륨은 파일 이름을 NFD의 변형, 즉 자모를 풀어 쓴 형태로 저장합니다. 이렇게 풀어 쓴 '보고서'는 9바이트가 아니라 18바이트이고, 변환기가 NFC로 합치면 몇 바이트가 되는지 알려 줍니다.
• 주소 속 %ED%95%9C를 읽을 때: 주소(URI)에 한글을 넣을 때는 먼저 UTF-8로 바꾼 뒤 바이트마다 %와 16진수 두 자리로 적습니다. 주소에서 복사한 %ED%95%9C%EA%B8%80을 넣으면 '한글'이 나옵니다.
• 코드에 문자열을 바이트 배열로 넣을 때: 임베디드 장치나 통신 규격에 글자를 보낼 때는 0xED, 0x95, 0x9C 같은 배열이 필요합니다. 형식을 '0x 배열'로 고르면 그대로 붙여 넣을 수 있는 모양으로 적습니다.

쓰는 법

1. 텍스트 칸에 글을 넣거나, 16진수 칸에 바이트를 붙여 넣습니다. 처음 화면에는 한글·영문·이모지 예시가 들어 있고, 위의 '예시' 단추로 숨은 문자, 풀어 쓴 한글, 로그의 \x 바이트, 깨진 바이트를 넣어 볼 수 있습니다.
2. 사이의 화살표가 변환 방향을 알려 줍니다. 텍스트 칸을 고치면 아래로(인코딩), 16진수 칸을 고치면 위로(디코딩) 바뀝니다.
3. 16진수 형식과 대문자·소문자를 고릅니다. 이미 16진수를 넣은 상태에서 형식을 바꾸면 같은 바이트를 새 형식으로 다시 적습니다.
4. 가운데 띠에서 글자를 누르거나 칸에서 커서를 옮기면, 비트 돋보기에 그 글자의 코드 포인트·UTF-8·UTF-16·EUC-KR(CP949) 바이트와 바이트 위치가 나옵니다.
5. '16진수 복사' 또는 '텍스트 복사'로 결과를 가져갑니다. 오른쪽 아래에서는 같은 글을 UTF-16·EUC-KR(CP949)로 저장할 때의 바이트 수를 비교합니다.

UTF-8이 글자를 바이트로 나누는 규칙

UTF-8은 유니코드 범위 U+0000~10FFFF의 글자를 1~4바이트로 적는 방식입니다(RFC 3629). 첫 바이트의 앞쪽 비트가 몇 바이트짜리 글자인지 알려 주고, 이어지는 바이트는 모두 10으로 시작합니다. 그래서 바이트 하나만 보고도 그것이 글자의 시작인지 중간인지 구분할 수 있습니다.

'한'을 직접 나눠 보면 이렇습니다. U+D55C를 2진수로 쓰면 1101 0101 0101 1100, 모두 16비트입니다. 3바이트 틀에는 4 + 6 + 6비트 자리가 있으므로 1101 / 010101 / 011100으로 나누어 11101101, 10010101, 10011100에 넣습니다. 이 세 바이트가 16진수로 ED, 95, 9C입니다. U+0000~007F는 1바이트 그대로라서 영문·숫자·기호만 있는 글은 ASCII와 바이트가 똑같습니다.

완성형 한글 음절 11,172자(가 U+AC00 ~ 힣 U+D7A3)는 모두 세 번째 줄에 들어가므로 UTF-8에서 늘 3바이트입니다. 그래서 '안녕하세요' 5자는 15바이트이고, 한글 첫 바이트는 EA·EB·EC·ED 가운데 하나가 됩니다.

글자별 UTF-8·UTF-16·EUC-KR 바이트

'뷁'의 EUC-KR 바이트 94 EE는 첫 바이트가 A1~FE 밖이라서, 원래 EUC-KR(KS X 1001) 범위가 아니라 Windows 코드 페이지 949가 덧붙인 확장 영역에 있습니다. 브라우저가 쓰는 euc-kr은 이 확장까지 포함하므로 한글 음절 11,172자를 모두 2바이트로 적을 수 있습니다.

같은 글, 인코딩마다 다른 바이트 수

영문만 있으면 UTF-8과 EUC-KR이 글자당 1바이트로 가장 짧고, 한글·한자는 UTF-8이 EUC-KR·UTF-16보다 1.5배 깁니다. 그래도 EUC-KR은 é·😀처럼 표에 없는 글자를 저장할 수 없습니다. WHATWG Encoding 표준도 UTF-8을 유니코드를 주고받기에 가장 알맞은 인코딩으로 보고, 새 프로토콜과 형식에는 UTF-8을 쓰도록 요구합니다. 가족 이모지는 화면에서 한 글자지만 사람 이모지 세 개(4바이트 × 3)를 ZWJ 두 개(3바이트 × 2)로 이은 것이라 18바이트입니다.

16진수를 적는 다섯 가지 형식

붙여 넣을 때는 형식을 고르지 않아도 됩니다. 공백·탭·줄바꿈·쉼표·콜론·하이픈을 구분자로 읽으므로, .NET의 BitConverter.ToString이 내는 ED-95-9C도 그대로 들어갑니다. \x와 % 형식은 그 사이에 그대로 적힌 영문·숫자도 바이트로 읽고, 앞뒤를 감싼 b'…'·"…"·[…]도 떼어 냅니다. 퍼센트 인코딩은 대문자 16진수를 쓰도록 권장되지만(RFC 3986), 대소문자는 같은 바이트입니다.

// JavaScript: 글 → UTF-8 16진수
[...new TextEncoder().encode('한글')].map(b => b.toString(16).padStart(2, '0')).join(' ');  // 'ed 95 9c ea b8 80'

# Python 3.8 이상: 글 ↔ 16진수
'한글'.encode('utf-8').hex(' ')                  # 'ed 95 9c ea b8 80'
bytes.fromhex('ED 95 9C EA B8 80').decode('utf-8')  # '한글' (공백은 무시)

UTF-8로 읽을 수 없는 바이트

모든 바이트 열이 UTF-8은 아닙니다. 이어지는 바이트가 시작 바이트 없이 나오거나, 글자가 중간에 끊기거나, 더 짧게 쓸 수 있는 글자를 일부러 길게 쓰면 잘못된 UTF-8입니다. RFC 3629는 서로게이트 자리(U+D800~DFFF)를 UTF-8로 적는 것을 금지하고, 디코더가 C0 80 같은 긴 형식(overlong)을 받아들이면 안 된다고 경고합니다. 브라우저는 잘못된 부분마다 대체 문자 �(U+FFFD) 하나를 넣는데, 이 변환기도 같은 규칙으로 나누고 띠에 오류 바이트와 이유를 표시합니다.

마지막 두 줄처럼 끊긴 글자는 그때까지 맞게 들어온 바이트를 묶어 � 하나로 바꿉니다. Unicode는 이것을 '최대 부분 열(maximal subpart)' 대체라고 부르며, 같은 바이트를 넣으면 브라우저와 이 변환기의 � 개수가 같습니다. 16진수 칸에 치는 중에는 마지막 글자가 덜 들어온 상태를 오류로 보지 않고 몇 바이트가 남았는지 알려 주고, 칸을 벗어나면 오류로 판정합니다.

깨진 모양으로 원래 인코딩 짐작하기

글이 깨지는 가장 흔한 이유는 한 인코딩으로 저장한 바이트를 다른 인코딩으로 읽는 것입니다. 깨진 모양에는 버릇이 있어서, 모양을 보고 어느 쪽에서 잘못 읽었는지 짐작할 수 있습니다.

�와 낯선 한글·한자가 섞여 있으면 인코딩이 서로 엇갈린 경우가 많고, ÷â·í 같은 라틴 문자가 두세 개씩 붙어 나오면 UTF-8을 라틴 인코딩으로 읽은 경우가 많습니다. 원래 바이트를 16진수 칸에 넣으면 변환기가 UTF-8로 읽어 보고, 읽을 수 없으면 EUC-KR(CP949)로 읽은 결과를 아래에 함께 적습니다. 예시의 '깨진 바이트'를 누르면 C7 D1 B1 DB 20 BB E7 C0 FC가 EUC-KR로는 '한글 사전'이라는 것을 볼 수 있습니다.

자주 틀리는 경우

• 숫자를 16진수로 바꾸는 계산으로 착각하는 경우: 텍스트 칸에 255를 넣으면 FF가 아니라 숫자 글자 '2'·'5'·'5'의 바이트 32 35 35가 나옵니다. 수의 진법을 바꾸려면 진법 변환기를 써야 합니다.
• 코드 포인트와 UTF-8 바이트를 섞어 쓰는 경우: U+D55C는 '한'의 번호이고 ED 95 9C는 그 번호를 UTF-8로 저장한 바이트입니다. 16진수 칸에 U+D55C나 \uD55C를 넣으면 바이트가 아니라는 안내가 나옵니다.
• 16진수 변환을 암호화로 여기는 경우: 16진수는 바이트를 적는 표기일 뿐이라 누구나 원래 글로 되돌릴 수 있습니다. 비밀번호나 개인정보를 가리는 용도로 쓰면 안 됩니다.
• 파일 맨 앞의 EF BB BF를 지워야 하는지 헷갈리는 경우: EF BB BF는 UTF-8 BOM(U+FEFF)이고, 맨 앞에 붙으면 'UTF-8 파일'이라는 서명 역할만 합니다. Unicode FAQ는 파일이 ASCII 글자로 시작하기를 기대하는 바이트 기반 프로토콜에서는 BOM을 피하라고 하고, 반대로 Microsoft의 .txt 파일 관례처럼 BOM을 요구하는 경우도 있다고 설명합니다. 받는 쪽이 BOM을 어떻게 다루는지 확인한 뒤 남기거나 지우세요.
• Windows 줄바꿈 0D 0A를 기대하는 경우: 브라우저 입력 칸은 줄바꿈을 LF(0A)로 바꿔 담습니다. 텍스트 칸에 친 줄바꿈은 0A이고, CR(0D)이 든 바이트를 확인하려면 16진수 칸에 0D 0A를 넣으세요.
• 글자 수와 바이트 수를 같게 보는 경우: 길이 제한이 바이트로 걸린 곳에서는 한글 10자가 30바이트로 셉니다. 띠 위의 '글자 · 코드 포인트 · 바이트' 세 숫자를 함께 보세요.

한계

• 변환은 브라우저 안에서만 하고, 입력한 글과 바이트는 서버로 보내거나 주소·저장소에 남기지 않습니다.
• 텍스트는 한 번에 UTF-16 기준 100,000자리, 16진수는 구분자를 포함해 1,200,000자리까지 바꿉니다. 띠는 앞 1,500개 글자·오류 바이트까지만 그리고, 나머지는 변환과 복사에만 들어갑니다.
• 16진수 출력은 UTF-8 바이트만 적습니다. UTF-16·EUC-KR(CP949)은 바이트 수 비교와 돋보기의 글자별 값으로만 보여 줍니다.
• EUC-KR(CP949) 값은 브라우저의 WHATWG Encoding 표를 따릅니다. 이 표준도 예전 인코딩은 프로그램마다 정의되지 않은 영역을 다르게 다뤄 왔다고 밝히므로, 오래된 프로그램과는 일부 글자가 다를 수 있습니다.
• 원문을 자동으로 정규화하지 않습니다. NFD로 풀어 쓴 글은 알림만 하고, 'NFC로 합치기'를 눌렀을 때만 바꿉니다.
• 이미지·압축 파일 같은 임의의 바이너리 파일은 다루지 않습니다. 파일을 글자로 옮기려면 Base64 도구를 쓰세요.
• % 인코딩을 읽을 때 +는 공백으로 바꾸지 않고 + 글자(2B)로 둡니다. 폼 데이터처럼 +가 공백을 뜻하는 값은 URL 인코더·디코더를 쓰세요.

출처

기준: UTF-8 규칙은 RFC 3629와 Unicode 18.0 핵심 명세 3장, 브라우저의 인코딩·디코딩과 EUC-KR 표는 WHATWG Encoding 표준, 그 밖의 형식과 오류 메시지는 각 문서로 2026년 10월 21일에 확인했습니다. UTF-8의 바이트 규칙은 RFC 3629 이후 바뀌지 않았습니다.

• 01RFC 3629 — UTF-8, a transformation format of ISO 10646U+0000~10FFFF를 1~4바이트로, 서로게이트 금지, C0 80 긴 형식 경고, BOM은 EF BB BF
• 02The Unicode Standard 18.0 — 3장 Conformance표 3-7 올바른 UTF-8 바이트 열, 3.9.6 최대 부분 열의 U+FFFD 대체
• 03WHATWG — Encoding Standard새 프로토콜·형식에는 UTF-8을 요구, UTF-8 디코더, TextDecoder fatal·ignoreBOM, euc-kr = KS X 1001 + 통합형 한글 코드(코드 페이지 949)
• 04Unicode — UTF-8, UTF-16, UTF-32 & BOM FAQ맨 앞 BOM은 서명, ASCII로 시작해야 하는 바이트 기반 프로토콜에서는 피하고 BOM을 요구하는 관례도 있음
• 05RFC 3986 — URI Generic Syntax2.1 퍼센트 인코딩은 대문자 16진수 권장, 2.5 UTF-8로 바꾼 뒤 퍼센트 인코딩
• 06MySQL 8.4 — The utf8mb3 Character Set문자당 최대 3바이트, BMP 글자만(보조 문자 미지원), utf8은 더는 권장하지 않는 별칭
• 07MySQL 8.4 — Server Error Message Reference오류 1366 ER_TRUNCATED_WRONG_VALUE_FOR_FIELD: Incorrect %s value: '%s' for column
• 08Python 3 — Built-in Types: bytesbytes.fromhex는 ASCII 공백 무시, bytes.hex(sep)는 3.8부터, ASCII 밖 바이트는 \x 이스케이프
• 09Microsoft Learn — BitConverter.ToString하이픈으로 나눈 16진수 쌍, 예: "7F-2C-4A-00"
• 10MDN — TextEncoderJavaScript 문자열을 늘 UTF-8로 인코딩
• 11Unicode Technical Standard #51 — Unicode Emoji개정 31(Emoji 18.0), ZWJ로 이은 이모지 시퀀스
• 12Unicode Standard Annex #15 — Normalization Forms개정 58, NFD = 정준 분해, NFC = 정준 분해 뒤 정준 합성
• 13Apple Technical Q&A QA1173 — Text Encodings in VFSHFS Plus(Mac OS 확장)는 파일 이름에 NFD의 변형을 씀

자주 묻는 질문

함께 쓰는 도구