Base64 인코딩 / 디코딩

Base64 인코딩·디코딩 방법

1. 텍스트를 Base64로 바꾸려면 인코딩을, Base64를 텍스트로 되돌리려면 디코딩을 고르세요.
2. 위쪽 상자에 입력하거나 붙여 넣으면 결과가 바로 나옵니다. 결과를 URL, 파일 이름, 토큰에 쓸 거라면 URL 안전 Base64에 체크하세요.
3. 복사를 누르거나, ⇅ 서로 바꾸기로 결과를 입력란으로 옮기고 방향을 뒤집으세요. 값이 원래대로 정확히 돌아오는지 확인할 때 편리합니다.

텍스트는 인코딩 전에 UTF-8 바이트로 바뀌므로 한글, 한자, 일본어, 아랍어, 악센트가 붙은 글자, 이모지 모두 문제없습니다. 디코더는 너그럽게 동작합니다. 줄바꿈과 공백을 무시하고, = 패딩이 있든 없든 받아들이며, 표준과 URL 안전 문자 집합을 모두 알아보고, 앞에 붙은 data:…;base64,도 떼어 냅니다. 디코딩한 바이트가 올바른 UTF-8 텍스트가 아니면 바이트 수와 파일 종류(PNG, JPEG, GIF, WebP, PDF, ZIP)를 알려 주고, 이미지는 미리 보여 주며, 디코딩된 파일 다운로드 버튼을 띄웁니다.

파일을 Base64로 변환

아래쪽 패널에서 파일을 고르면 바로 Base64가 나오고, 파일 이름, 크기, Base64 결과의 길이가 함께 표시됩니다. data URL 접두어 포함에 체크하면 결과가 data:image/png;base64,처럼 시작하므로 HTML의 src 속성이나 CSS의 url()에 바로 붙여 넣을 수 있습니다. 체크를 풀면 Base64만 나옵니다. 접두어의 파일 형식은 브라우저가 알려 주는 값이며, 브라우저가 모르는 형식이면 application/octet-stream이 들어갑니다. 파일은 브라우저가 직접 읽으며 업로드되지 않습니다.

Base64의 원리

Base64는 입력을 3바이트(24비트)씩 끊어 6비트짜리 네 묶음으로 나눕니다. 0부터 63까지의 각 6비트 값을 A–Z(0–25), a–z(26–51), 0–9(52–61), +(62), /(63) 중 한 글자로 씁니다. 대표적인 예가 영어 단어 Man입니다. 세 바이트 01001101 01100001 01101110을 다시 묶으면 010011 010110 000101 101110, 즉 19, 22, 5, 46이 되고 문자로는 TWFu입니다.

입력 길이가 3의 배수가 아니면 마지막 묶음에 패딩을 붙입니다. Ma는 TWE=, M은 TQ==가 됩니다. 3바이트가 4글자가 되므로 Base64는 원본보다 약 3분의 1 커집니다. 100바이트는 136자, 1,000바이트는 1,336자가 됩니다. 문자 집합, 패딩, URL 안전 방식은 모두 RFC 4648에 정의되어 있습니다. 이메일(MIME)은 여기에 더해 Base64를 한 줄 76자 이하로 나누는데, 이 도구는 끊김 없는 한 줄로 출력하고 줄이 나뉜 입력도 문제없이 디코딩합니다.

예시

한글은 UTF-8에서 한 글자가 3바이트이므로 “안녕하세요” 다섯 글자는 15바이트, Base64로는 20자가 됩니다. 15바이트는 3의 배수라서 패딩이 붙지 않습니다.

URL 안전 Base64 (base64url)

URL에서 +는 공백으로 해석될 수 있고, /는 경로를 나누며, =는 쿼리 문자열에서 특별한 의미가 있습니다. URL 안전 방식은 +를 -로, /를 _로 바꾸고, 표의 마지막 행처럼 보통 패딩을 뺍니다. JSON 웹 토큰(JWT)은 세 부분 모두에 이 방식을 씁니다. 디코딩할 때는 어느 방식인지 알려 줄 필요가 없으며, 둘 다 자동으로 알아봅니다.

Base64를 만나는 곳

• data URL은 작은 이미지나 글꼴을 HTML, CSS 안에 바로 넣을 때 씁니다.
• 이메일 첨부 파일은 메시지 안에 Base64로 들어가 전송됩니다.
• HTTP 기본 인증은 사용자이름:비밀번호를 Base64로 보냅니다. 표준 문서의 예인 Aladdin:open sesame은 QWxhZGRpbjpvcGVuIHNlc2FtZQ==가 되는데, 기본 인증이 HTTPS에서만 안전한 이유도 여기서 알 수 있습니다.
• API와 JSON은 이미지, 서명, 키 같은 바이너리 데이터를 텍스트 필드에 담을 때 Base64를 씁니다.

알아 두면 좋은 앞부분도 있습니다. iVBORw0KGgo로 시작하면 PNG 파일, /9j/는 JPEG, JVBERi0는 PDF, eyJ는 대개 JWT 헤더 같은 JSON 객체입니다.

디코딩이 잘 안 될 때

• “입력에 Base64에서 쓰지 않는 문자가 있습니다” – 값과 함께 따옴표나 문장 부호가 복사된 경우가 많습니다. URL에서 가져온 문자열에 %3D나 %2F가 있다면 먼저 URL 인코딩 / 디코딩으로 디코딩하세요.
• “입력 길이가 올바르지 않습니다” – 복사하다가 끝이 잘리는 등 문자열 일부가 빠진 것입니다.
• 텍스트 대신 바이너리 데이터로 나올 때 – 실제로 파일이거나, UTF-8이 아닌 예전 인코딩으로 저장된 텍스트입니다. 예를 들어 EUC-KR(CP949)로 저장된 “안녕”의 Base64인 vsiz5w==는 올바른 UTF-8이 아니므로 4바이트 바이너리로 나옵니다. 워드·엑셀 파일(.docx, .xlsx)은 ZIP 형식이라 decoded.zip으로 저장되니, 원래 확장자로 이름을 바꾸세요.

자주 묻는 질문

Base64는 암호화인가요?

아니요. 키가 없는, 되돌릴 수 있는 인코딩이라 누구나 바로 디코딩할 수 있습니다. 비밀번호나 개인정보를 숨기는 용도로 쓰면 안 됩니다.

결과 끝에 = 나 ==가 붙는 이유는 무엇인가요?

패딩입니다. 입력을 3바이트씩 나누고 2바이트가 남으면 = 하나, 1바이트가 남으면 두 개가 붙습니다. 마지막 묶음에 몇 바이트가 들어 있는지 디코더에 알려 주는 역할입니다.

여기서 JWT를 디코딩할 수 있나요?

점으로 나뉜 세 부분을 하나씩 디코딩할 수는 있지만, JWT 디코더를 쓰면 토큰을 자동으로 나눠 헤더와 페이로드를 정리된 JSON으로, 날짜는 읽기 쉬운 형태로 보여 줍니다.

얼마나 큰 파일까지 변환할 수 있나요?

한계는 브라우저의 메모리입니다. 다만 data URL은 작은 파일에 알맞습니다. 큰 이미지를 Base64로 넣으면 페이지가 3분의 1만큼 무거워지고, 이미지를 페이지와 따로 캐시할 수도 없습니다.