Base64는 암호화가 아니다
Base64는 임의의 바이트를 64개의 안전한 문자(A–Z, a–z, 0–9, +, /)만으로 적는 표기법입니다. 누구나 되돌릴 수 있고 키도 없습니다. 비밀번호나 토큰을 Base64로 바꿔 놓았다고 해서 보호되는 것은 전혀 아닙니다. 목적은 텍스트만 다룰 수 있는 통로(이메일, JSON, URL, HTML 속성)에 바이너리를 실어 보내는 것입니다. 이 페이지의 변환은 브라우저 안에서만 일어나고 입력은 서버로 가지 않습니다.
한글이 깨지는 이유와 해결
브라우저의 btoa()는 0–255 범위의 바이트 문자열만 받습니다. 한글은 UTF-16 코드 단위가 255를 넘기 때문에 그대로 넣으면 오류가 나거나, 다른 도구에서는 깨진 글자가 나옵니다. 올바른 방법은 문자열을 먼저 UTF-8 바이트로 바꾼 뒤(TextEncoder) 그 바이트를 Base64로 만드는 것이고, 디코딩은 반대 순서입니다. 이 도구는 그 방식을 쓰므로 다른 언어(Python의 base64.b64encode(s.encode('utf-8')) 등)와 결과가 같습니다.
URL-safe 변형
표준 Base64의 +와 /는 URL에서 특별한 뜻이 있어 그대로 쓰면 깨집니다. RFC 4648의 URL-safe 변형은 이 둘을 -와 _로 바꾸고, 끝의 = 패딩을 보통 생략합니다. JWT 토큰의 각 부분이 바로 이 형식입니다. 디코딩 시에는 두 형식 모두 자동으로 받아들이며 빠진 패딩도 채워서 처리합니다.
크기가 늘어나는 비율
3바이트가 4글자로 바뀌므로 원본보다 약 33% 커집니다. 이미지를 data URI로 HTML에 넣을 때 파일이 커지는 이유입니다. 작은 아이콘 정도면 요청 수를 줄이는 이점이 있지만, 수십 KB 이상이면 별도 파일로 두는 편이 낫습니다.
자주 묻는 질문
디코딩했더니 이상한 기호만 나와요.
원본이 텍스트가 아니라 이미지·PDF 같은 바이너리일 가능성이 큽니다. 그 경우 앞부분 16진수를 보여 드리며, 텍스트로는 복원할 수 없습니다.
다른 사이트와 결과가 달라요.
한글이 포함된 경우 그 사이트가 UTF-8이 아닌 방식(Latin-1 등)으로 바이트를 만들었을 수 있습니다. 영문·숫자만 있으면 결과는 항상 같습니다.
끝에 = 가 붙는 이유는요?
입력 바이트 수가 3의 배수가 아닐 때 길이를 4의 배수로 맞추기 위한 패딩입니다. 데이터에는 영향이 없고, URL-safe 형식에서는 보통 생략합니다.