Base64 인코더·디코더

텍스트를 Base64 표현으로 인코딩하거나 디코딩합니다.

일반 문자열을 Base64로 인코딩하거나 Base64 문자열을 원래 텍스트로 디코딩합니다. 표준 형식과 URL-safe 형식을 모두 지원합니다.

사용 순서

왼쪽 입력 칸에 문자열을 넣으면 아래 칸에 Base64 결과가 나옵니다.
URL-safe 스위치를 켜면 +와 /가 각각 -와 _로 바뀌고 끝의 = 패딩이 빠집니다.
아래쪽 Base64 입력 칸에 값을 넣으면 디코딩 결과가 표시됩니다. 유효하지 않은 값이면 오류 문구가 뜹니다.
디코딩할 때는 Decode URL safe 스위치를 입력 형식에 맞게 설정합니다.

예시

Hello를 인코딩하면 SGVsbG8=이 되고, URL-safe를 켜면 끝의 = 패딩을 뺀 SGVsbG8이 됩니다.

한계

입력은 UTF-8 바이트로 바꿔 인코딩하므로 한글처럼 여러 바이트인 글자는 결과가 길어집니다. 표준 모드에서는 = 패딩이 빠진 문자열을 유효하지 않다고 판단합니다. 디코딩 시 data:...;base64, 접두사는 자동으로 제거되며 앞뒤 공백도 무시합니다. 디코딩 결과가 UTF-8 텍스트가 아니면 깨진 문자가 보일 수 있습니다.

보안 주의

JWT 토큰의 가운데 부분은 Base64URL로 인코딩된 JSON이라 디코딩하면 사용자 ID와 만료 시각이 그대로 보입니다. 화면을 공유하거나 이슈에 붙여 넣기 전에 실제 토큰을 지우세요.

배경 지식

Base64는 임의의 바이트를 A부터 Z, a부터 z, 0부터 9, +, / 64개 문자로 바꾸는 표기 방식입니다. 3바이트를 4문자로 나누므로 원래 크기보다 약 33% 커집니다. 암호화가 아니라 표기를 바꾼 것이어서 누구나 키 없이 되돌릴 수 있습니다. 그래서 Base64 문자열을 보고 민감한 정보가 없다고 판단하면 안 됩니다.

문자열을 Base64로 바꾸는 이유는 이메일 본문, JSON, URL처럼 제어 문자나 바이너리를 안전하게 싣기 위해서입니다. URL에서는 +, /, = 기호가 특별한 의미를 가지므로 - 와 _ 를 쓰는 URL-safe 변형이 따로 쓰입니다. JWT도 이 변형을 씁니다.

한글처럼 한 글자가 여러 바이트인 문자는 UTF-8로 인코딩한 바이트를 기준으로 계산됩니다. 인코딩한 뒤 디코딩 결과가 깨졌다면 원본 문자열이 UTF-8이었는지, 다른 인코딩을 쓴 시스템에서 만들어졌는지 먼저 확인하세요. 인코딩 문제는 한글이 물음표나 깨진 글자로 보일 때 대부분 드러납니다.

자주 묻는 질문

Base64 문자열 끝에 = 기호가 붙는 이유는 무엇인가요?

Base64는 원본을 3바이트씩 끊어 4문자로 바꾸는데, 마지막 조각이 부족하면 = 로 채웁니다. 1바이트가 남으면 ==가, 2바이트가 남으면 =가 붙습니다. URL-safe 형식은 이 패딩을 생략하는 경우가 많습니다.

Base64로 인코딩하면 비밀번호가 안전해지나요?

안전해지지 않습니다. Base64는 키 없이 누구나 되돌릴 수 있으므로 비밀번호 보호에는 쓰면 안 되고, 비밀번호는 bcrypt 같은 해시나 암호화로 보호해야 합니다.

URL-safe 스위치는 언제 켜야 하나요?

값을 URL 경로나 쿼리 문자열에 넣을 때, 그리고 JWT처럼 base64url 형식의 값을 디코딩할 때 켜는 것이 맞습니다. + 나 / 가 그대로 URL에 들어가면 서버가 다른 값으로 읽을 수 있습니다.