⇄ Base64 Codec

텍스트와 Base64를 오가는 인코더/디코더. UTF-8(한글·이모지) 안전.

plain.txt

encoded.b64

ready.

사용법

원문을 왼쪽 plain.txt에 입력하고 Encode →를 누르면 오른쪽 encoded.b64에 Base64 문자열이 나옵니다.
반대로 오른쪽에 Base64를 붙여넣고 ← Decode를 누르면 왼쪽에 원래 텍스트가 복원됩니다.
URL-safe를 체크한 채 인코딩하면 URL·파일명에 바로 넣을 수 있는 형태로 출력됩니다.
Swap은 두 칸의 내용을 맞바꾸고, Copy output은 마지막으로 결과가 나온 칸을 복사합니다.

Base64란?

Base64는 바이너리 데이터를 A–Z, a–z, 0–9, +, / 64개 문자만으로 표현하는 인코딩입니다. 이메일 첨부, data URL 이미지, HTTP Basic 인증 헤더, JWT처럼 "텍스트만 지나갈 수 있는 통로"에 바이트를 실어 보낼 때 씁니다.

원리는 간단합니다. 3바이트(24비트)를 6비트씩 4조각으로 나누고, 각 조각(0~63)을 문자표의 한 글자로 바꿉니다. 그래서 결과는 원본보다 약 33% 길어집니다. 마지막에 3바이트가 안 채워지면 =를 1~2개 붙여 길이를 4의 배수로 맞춥니다. 예: Man → TWFu, Ma → TWE=.

한글이 깨지지 않는 이유

이 도구는 텍스트를 먼저 UTF-8 바이트로 바꾼 뒤 Base64로 인코딩합니다. 한글 한 글자는 UTF-8로 3바이트, 이모지는 보통 4바이트이므로 안녕(6바이트)은 7JWI64WV(8글자)가 됩니다. 디코딩할 때도 UTF-8로 엄격하게 해석하며, 결과가 올바른 UTF-8 텍스트가 아니면 오류를 표시합니다.

URL-safe Base64

구분	62번째	63번째	패딩
표준 Base64	`+`	`/`	`=` 붙임
URL-safe (Base64URL)	`-`	`_`	생략

디코딩은 체크 여부와 상관없이 두 형식을 모두 받아들입니다. -, _를 자동으로 되돌리고 빠진 =도 채워 주며, 중간의 공백·줄바꿈은 무시합니다.

Base64는 암호화가 아닙니다. 누구나 즉시 디코딩할 수 있으니 비밀번호나 개인정보를 "가리는" 용도로 쓰면 안 됩니다. 또 이 도구는 텍스트 전용이라 이미지·PDF 같은 바이너리를 디코딩하면 UTF-8 오류가 납니다.

자주 묻는 질문

Base64 디코딩하면 한글이 깨져요

원본이 UTF-8이 아닌 EUC-KR(CP949)로 인코딩된 경우입니다. 이 도구는 UTF-8만 해석하므로 "not UTF-8 text" 오류가 표시됩니다. 대부분의 최신 시스템은 UTF-8을 쓰니 생성한 쪽의 문자셋을 확인해 보세요.

끝에 붙은 == 는 무엇인가요?

패딩입니다. 원본 바이트 수가 3의 배수가 아닐 때 길이를 4의 배수로 맞추려고 붙입니다. 1바이트가 남으면 ==, 2바이트가 남으면 =가 붙습니다.

Base64로 바꾸면 용량이 얼마나 늘어나나요?

3바이트가 4글자가 되므로 약 4/3배, 즉 33% 정도 커집니다. 한글은 글자당 3바이트라 한글 1글자가 Base64 4글자에 해당합니다.

JWT 안의 내용을 보려면 이 도구를 써도 되나요?

JWT의 각 부분은 URL-safe Base64라서 디코딩은 가능하지만, 점(.)으로 나눠 한 조각씩 넣어야 합니다. JWT 디코더를 쓰면 헤더·페이로드·만료 시간을 한 번에 볼 수 있습니다.

이 도구와 함께 보면 좋은 글

개발자 · 2026. 10. 1.JWT 보안 체크리스트 — alg none, 알고리즘 혼동, 토큰 저장 위치JWT 사고는 규격이 아니라 쓰는 방식에서 나요. verify 옵션으로 막히는 alg none·알고리즘 혼동을 재현하고, 약한 비밀 키가 얼마나 빨리 풀리는지 계산했어요. 키 관리, 페이로드, 저장 위치까지 10개 항목으로 정리했습니다.개발자 · 2026. 9. 14.Base64 용도 5가지와 용량 33% 증가 원리 — data URI·이메일·PEMBase64는 data URI, 이메일 첨부, HTTP Basic 인증, JSON 속 바이너리, PEM 인증서에서 쓰여요. 3바이트가 4글자가 되는 원리와 입력 크기별 실제 증가율, gzip 후엔 차이가 얼마나 줄어드는지 직접 재 본 결과까지 정리했습니다.개발자 · 2026. 8. 2.URL-safe Base64(Base64URL) 차이와 패딩 = 복원, Incorrect padding 해결표준 Base64의 +, /, = 는 URL에서 공백·경로·구분자로 오해돼 토큰이 가끔 깨져요. Base64URL은 -와 _를 쓰고 패딩을 뺀 변형이에요. JS·Python·Java 변환 코드, Incorrect padding 같은 실제 에러 해결법을 정리했습니다.개발자 · 2026. 7. 9.Base64는 암호화가 아니다 — 인코딩·암호화·해시 차이와 올바른 사용법Base64는 키 없이 누구나 1초 만에 되돌리는 인코딩이라 비밀을 지켜 주지 못해요. 인코딩·암호화·해시의 차이를 Node 코드로 직접 비교하고, 비밀번호와 민감 데이터를 실제로 어떻게 저장해야 하는지 정리했습니다.개발자 · 2026. 7. 3.JWT 구조와 서명 원리 — 헤더·페이로드·서명, HS256과 RS256 차이eyJ로 시작하는 JWT는 헤더.페이로드.서명 세 부분이고, 앞의 둘은 누구나 읽을 수 있는 Base64URL이에요. Node 내장 crypto로 HS256 토큰을 직접 만들고 검증해 보고, HS256·RS256·ES256의 토큰 길이와 속도를 실측해 비교했습니다.개발자 · 2026. 10. 4.URL 인코딩 원리와 한글 URL, encodeURI vs encodeURIComponent 차이URL 인코딩은 문자를 UTF-8 바이트로 바꾼 뒤 바이트마다 %XX로 쓰는 방식이라 한글 1자가 9자로 늘어요. encodeURI와 encodeURIComponent가 무엇을 남기는지, 공백 %20과 +, 이중 인코딩·EUC-KR 깨짐·URIError까지 실제 실행 결과로 정리했어요.