Base64 인코더/디코더

Base64 인코더/디코더 소개

Base64는 임의의 바이트를 영문 대소문자, 숫자, +, / 64개 문자만으로 옮겨 적는 방법입니다. 이메일 첨부 파일, HTTP Basic 인증 헤더, JWT, 이미지 data URI처럼 「텍스트만 지나갈 수 있는 통로」로 바이너리를 보내야 할 때 씁니다.

이 도구는 입력한 텍스트를 먼저 UTF-8 바이트로 바꾼 다음 그 바이트를 Base64로 적습니다. 디코딩할 때는 표준 알파벳(+ /)과 URL-safe 알파벳(- _)을 모두 받아들이고, 끝의 = 패딩이나 중간의 공백·줄바꿈이 있어도 없어도 처리합니다.

3바이트가 4글자가 되는 원리

RFC 4648은 입력을 3바이트(24비트)씩 끊고, 24비트를 6비트 네 조각으로 나눠 각 조각(0~63)을 알파벳 한 글자로 바꾸라고 정합니다. 「Man」은 바이트 4D 61 6E이고, 비트로 풀면 010011 010110 000101 101110, 즉 19·22·5·46이라 TWFu가 됩니다.

마지막 묶음이 3바이트가 안 되면 = 로 채웁니다. 1바이트가 남으면 두 글자 뒤에 ==, 2바이트가 남으면 세 글자 뒤에 = 하나가 붙습니다. 「M」은 TQ==, 「Ma」는 TWE=가 됩니다. 그래서 패딩까지 포함한 Base64 길이는 항상 4의 배수입니다.

크기는 ceil(n/3)×4 글자입니다. 30,000바이트 파일은 정확히 40,000글자(33% 증가)가 되고, 100바이트는 136글자(36%)가 됩니다. 입력이 작을수록 패딩 때문에 비율이 33%보다 조금 커집니다. MIME 이메일은 여기에 76글자마다 줄바꿈(CRLF)을 넣으므로 실제 첨부는 약 35% 더 커집니다.

Base64는 암호화가 아니다

Base64에는 키가 없습니다. 알파벳표만 있으면 누구나 원문을 되돌릴 수 있고, 이 도구가 바로 그 일을 합니다. 「dXNlcjpwYXNz」처럼 알아보기 어렵게 생겼을 뿐 내용은 user:pass 그대로입니다.

HTTP Basic 인증(RFC 7617)은 「아이디:비밀번호」를 Base64로 적어 Authorization 헤더에 넣습니다. HTTPS가 아니면 이 헤더를 본 사람은 비밀번호를 그대로 읽습니다. JWT도 마찬가지로 헤더와 페이로드는 Base64url로 적혀 있을 뿐 암호화되지 않았습니다. 서명은 위조를 막지만 내용을 숨기지는 않으므로, 토큰의 가운데 부분을 이 도구에 넣으면 사용자 ID나 만료 시간이 보입니다. 비밀번호나 개인정보를 페이로드에 넣으면 안 되는 이유입니다.

btoa()가 한글에서 오류를 내는 이유

브라우저의 btoa()는 문자열의 각 글자를 한 바이트(0~255)로 간주합니다. 「한」은 코드 포인트가 U+D55C라 한 바이트에 들어가지 않으므로 btoa("한글")은 InvalidCharacterError를 냅니다. 오류가 나지 않는 é 같은 라틴 문자도 UTF-8(2바이트)이 아니라 Latin-1(1바이트)로 인코딩되어, 다른 시스템에서 UTF-8로 디코딩하면 깨집니다.

올바른 순서는 텍스트 → UTF-8 바이트 → Base64입니다. 이 도구는 TextEncoder로 UTF-8 바이트를 만든 뒤 직접 변환하므로 「한글」은 6바이트(ED 95 9C EA B8 80)를 거쳐 7ZWc6riA가 됩니다. 반대로 서버에서 EUC-KR로 인코딩한 Base64를 넣으면 이 도구는 UTF-8로 읽기 때문에 � 문자가 섞여 나옵니다.

표준 Base64와 Base64url

표준 알파벳의 +와 /는 URL과 파일 이름에서 특별한 뜻이 있습니다. RFC 4648 5절은 이 둘을 -와 _로 바꾼 「URL and Filename safe」 알파벳을 따로 정의합니다. JWT는 여기에 패딩 =까지 빼는 방식을 씁니다.

이 도구의 URL-safe 옵션도 +→-, /→_ 치환 후 끝의 =를 지웁니다. 「<<???>>」는 표준으로 PDw/Pz8+Pg==, URL-safe로 PDw_Pz8-Pg입니다. 표준 Base64를 쿼리 문자열에 그대로 넣으면 +가 공백으로 바뀌어 디코딩이 깨지는 경우가 흔하니, URL에 넣을 값은 URL-safe로 만들거나 퍼센트 인코딩을 한 번 더 하세요.

예시

사용 방법

1. 인코딩 방향이면 텍스트를, 디코딩 방향이면 Base64 문자열을 붙여 넣습니다.
2. URL이나 JWT에 넣을 값이라면 URL-safe 옵션을 켭니다(인코딩 방향에서만 적용).
3. 방향 전환 버튼으로 결과를 다시 입력 쪽으로 돌려 왕복이 맞는지 확인할 수 있습니다.

주요 용어

패딩(=)

마지막 묶음이 3바이트보다 짧을 때 출력 길이를 4의 배수로 맞추려고 붙이는 문자. 정보는 담지 않습니다.

Base64url

RFC 4648 5절의 변형. + 대신 -, / 대신 _를 씁니다. JWT와 URL 파라미터에 쓰입니다.

UTF-8

유니코드 문자를 1~4바이트로 적는 인코딩. 한글 한 글자는 3바이트, 이모지는 대개 4바이트입니다.

자주 묻는 질문