Base64 인코드 / 디코드
브라우저에서 텍스트를 Base64로 인코딩하거나 Base64를 텍스트로 디코딩합니다. 무료, 데이터 업로드 불필요.
- 브라우저에서 처리
- 데이터가 브라우저 밖으로 나가지 않습니다
- 무료 · 회원가입 불필요
WeChat으로 스캔하여 공유
예시·자세한 설명·자주 묻는 질문 실제 출력이 있는 예시, 다른 도구와의 차이, 자주 묻는 질문.
한글 인코딩 결과
이 도구는 텍스트를 먼저 UTF-8 바이트로 바꾼 뒤 Base64로 인코딩합니다. 완성형 한글 음절은 UTF-8에서 한 글자에 3바이트이므로, 한글만 있는 문자열은 글자 수의 4배 길이가 됩니다.
안녕하세요(5글자, 15바이트)를 Standard로 인코딩하면 7JWI64WV7ZWY7IS47JqU가 나옵니다. 20글자이고 끝에 =가 붙지 않습니다.
JWT 페이로드 속 한글 이름
로그인 토큰(JWT)의 가운데 부분은 패딩 없는 URL-safe Base64입니다(RFC 7515 제2절). 페이로드에 한글 이름이 들어 있으면 -나 _가 섞일 수 있습니다. 예를 들어 {"name":"홍길동"}의 페이로드는 eyJuYW1lIjoi7ZmN6ri464-ZIn0입니다.
이 문자열을 Standard 모드에서 디코딩하면 - 때문에 23번째 문자: "-"은(는) URL-safe 알파벳의 문자입니다. URL-safe로 바꿔 디코딩하세요.라는 오류가 납니다.
URL-safe로 바꾸면 바로 {"name":"홍길동"}이 표시됩니다. 헤더·페이로드·서명을 한 번에 나눠 보려면 JWT 디코더를 쓰세요. 두 도구 모두 서명은 검증하지 않습니다.
EUC-KR로 저장된 텍스트
오래된 시스템이나 파일은 한글을 EUC-KR로 저장하는 경우가 있습니다. 같은 홍길동이라도 UTF-8은 7ZmN6ri464+Z, EUC-KR 바이트(C8 AB B1 E6 B5 BF)는 yKux5rW/로 Base64가 달라집니다. Python의 base64.b64encode('홍길동'.encode('euc-kr'))로 확인할 수 있습니다.
yKux5rW/를 붙여 넣으면 깨진 글자 대신 디코딩한 데이터의 3번째 바이트(B1)는 올바른 UTF-8이 아닙니다. 디코딩 결과는 UTF-8 텍스트만 표시하므로 바이너리 데이터나 EUC-KR 등의 텍스트는 표시할 수 없습니다.가 표시됩니다. Base64 자체는 올바르지만 풀어낸 6바이트가 UTF-8이 아닙니다. 첫 두 바이트 C8 AB는 우연히 UTF-8 문자 하나로 읽히기 때문에, 처음으로 맞지 않는 세 번째 바이트 B1이 표시됩니다. EUC-KR 같은 기존 인코딩은 원래 인코딩을 지정할 수 있는 프로그램에서 읽어야 합니다.
디코딩할 때 허용되는 입력
- 끝의
=는 생략해도 됩니다. 브라우저의atob()는 WHATWG의 forgiving-base64 decode를 따르며 패딩을 요구하지 않습니다. - 줄바꿈, 탭, 공백은 Standard와 URL-safe 두 모드 모두에서 무시합니다. 76글자마다 줄이 바뀐 메일 본문의 Base64도 그대로 붙여 넣을 수 있습니다. 앞의 JWT 페이로드를
eyJuYW1lIjoi7ZmN6ri4에서 줄을 바꿔 붙여 넣어도 URL-safe에서{"name":"홍길동"}이 나옵니다. - URL-safe 모드는
-와_를+와/로 되돌리기만 하므로 Standard 문자열도 읽습니다.
제한 사항
- 디코딩 결과는 UTF-8 텍스트로만 표시합니다. 이미지 같은 파일로 되돌릴 수는 없습니다.
- 문자열 중간에
=가 있거나, 4글자씩 나누고 1글자가 남으면 오류가 나며, 상태 줄에=의 위치나 글자 수가 표시됩니다. - 이모지 반쪽(짝이 없는 서로게이트)이 남은 텍스트는 UTF-8로 바꿀 수 없어 인코딩 시 위치와 함께 오류를 표시합니다.
- 파일 인코딩에는 정해진 크기 제한이 없지만, 5 MiB(5,242,880바이트)를 넘으면
파일이 커서 인코딩에 몇 초 걸릴 수 있습니다.라고 표시합니다. 파일 전체와 결과를 메모리에 두므로 아주 큰 파일은 페이지를 느리게 만듭니다. - Base64는 암호화가 아니므로 누구나 디코딩할 수 있습니다. 비밀 정보에는 AES 암호화 도구를 사용하세요.
주요 사용 사례
- API 인증: HTTP Basic 인증은
사용자명:비밀번호를 Base64로 바꿔 헤더에 넣습니다(RFC 7617). - Data URI: CSS나 HTML에 넣는 이미지와 폰트는 Base64입니다. 이미지는 이미지 Base64 변환기가 파일 내용으로 종류를 판단합니다.
- JWT 토큰: 헤더와 페이로드는 URL-safe Base64입니다.
- 이메일: 첨부 파일은 Base64로 전송되며, 비ASCII 제목도 Base64(RFC 2047의 B 인코딩)로 쓸 수 있습니다.
FAQ
Base64란 무엇입니까?
Base64는 바이너리 데이터를 ASCII 텍스트로 변환하는 인코딩 방식으로, 64종류의 인쇄 가능한 문자를 사용합니다. Data URI, 이메일 첨부 파일, API 토큰 등에 자주 사용됩니다.
데이터가 서버로 전송됩니까?
아니요. 변환은 브라우저 안에서 JavaScript 내장 함수 btoa / atob로 처리하며, 입력한 텍스트와 선택한 파일을 외부로 보내지 않습니다. 마지막으로 입력한 텍스트는 다음에 열 때 복원하도록 이 브라우저의 로컬 저장소에 저장됩니다. 파일은 저장하지 않으며, 지우기를 누르면 저장된 텍스트도 삭제됩니다.
바이너리 파일도 인코딩할 수 있습니까?
예. 인코딩 모드에서 파일을 업로드 영역에 끌어 놓거나 영역을 클릭해 선택합니다. 종류와 관계없이 파일의 바이트를 그대로 Base64로 바꾸며, data:<mime>;base64, 접두사도 붙일 수 있습니다. 디코딩 결과는 UTF-8 텍스트로만 표시하므로 이미지 같은 바이너리 데이터의 Base64는 오류가 나고 파일로 저장할 수 없습니다. 이미지를 Data URI로 바꿀 때는 이미지 Base64 변환기를 사용하세요.
디코딩에 실패하는 이유는 무엇입니까?
원인은 세 가지입니다. Base64에 없는 문자가 들어 있는 경우(Standard를 선택한 채 URL-safe의 - 나 _ 를 넣은 경우 등), 문자열이 잘려 4글자 단위로 1글자가 남는 경우, 디코딩한 바이트가 UTF-8로 읽히지 않는 경우(바이너리 데이터나 EUC-KR 텍스트)입니다. 끝의 = 가 빠져 있어도 디코딩됩니다. 상태 줄에는 원인과 위치(입력의 몇 번째 문자인지, 디코딩 결과의 몇 번째 바이트인지)가 표시됩니다.