Base64 인코더ㆍ디코더

Base64란?

Base64는 바이너리 데이터를 ASCII 문자(A-Z, a-z, 0-9, +, /)만 사용해 표현하는 인코딩 방식입니다. 이메일, 데이터 URI, JWT, API 응답 등에 널리 쓰입니다.

Smart Input Detection

텍스트를 붙여넣을 때 Base64 형태(허용 문자 + 길이가 4의 배수)인지 판단해 자동으로 디코딩 모드로 전환합니다.

안전성

입력한 텍스트와 파일은 브라우저에서만 처리되며 서버로 전송되지 않습니다. 민감한 토큰이나 자격 증명도 안심하고 다룰 수 있습니다.

인코딩의 실제 동작 원리

Base64는 3바이트(24비트)씩 입력을 받아 6비트씩 4개로 쪼갠 뒤, 각각을 인쇄 가능한 ASCII 문자 하나로 대응시킵니다. 문자 집합은 RFC 4648에 정의되어 있습니다. 입력 길이가 3의 배수가 아니면 결과 끝에 =가 1~2개 붙어 출력이 항상 4의 배수 길이가 됩니다. 따라서 "길이가 4의 배수이고, 모든 문자가 [A-Za-z0-9+/=] 범위 안에 있는가"가 Base64 여부를 빠르게 판별하는 기준입니다.

일상에서 Base64를 만나는 곳

• Data URI - <img src="data:image/png;base64,iVBOR...">처럼 HTMLㆍCSS 안에 이미지를 직접 삽입하는 방식. 2KB 미만의 아이콘에 적합하며, 크기가 커지면 별도 요청과 달리 병렬 처리가 안 돼 렌더링 성능이 떨어집니다.
• JWT(JSON Web Token) - 헤더와 페이로드는 Base64URL 인코딩(표준 Base64와 다름)으로 점(.)으로 연결됩니다. 점 기준으로 분리한 뒤 앞 두 세그먼트를 디코딩하면 내용을 확인할 수 있습니다. JWT는 서명이지 암호화가 아니므로, 토큰 본문에 비밀 정보를 넣으면 안 됩니다.
• MIME 이메일 첨부 - SMTP는 원래 7비트 ASCII만 지원해, 이진 파일은 Content-Transfer-Encoding: base64로 감싸고 76자씩 줄을 나눠 전송합니다.
• HTTP Basic 인증 - Authorization: Basic dXNlcjpwYXNz는 base64("user:pass")일 뿐입니다. 평문 연결에서 스니핑하면 즉시 디코딩됩니다. Basic 인증은 반드시 HTTPS와 함께 써야 합니다.
• SSHㆍPEM 키, 인증서 - -----BEGIN PRIVATE KEY-----와 -----END PRIVATE KEY----- 사이의 텍스트는 DER 이진 데이터를 Base64로 감싼 PEM 형식입니다.
• OAuth 상태값, API 키, CSP nonce - "불투명 토큰"의 대부분은 URL-safe 문자만 쓰는 Base64URL로 인코딩된 난수 바이트입니다.

Base64 vs Base64URL - 올바른 방식 선택

표준 Base64는 +, /, =를 사용합니다. 이 중 두 문자는 URL에서 특수 의미를 가져(+는 공백, /는 경로 구분자), 쿼리 문자열에 그대로 넣으면 값이 깨집니다. 이를 해결하는 Base64URL(RFC 4648 §5)은 +를 -로, /를 _로 치환하고, 보통 = 패딩을 생략합니다. 선택 기준은 간단합니다.

• Base64URL 사용 - URL, 파일명, HTTP 헤더에 값이 들어가는 경우. JWT, OAuth 토큰, 파일 캐시 키 등.
• 표준 Base64 사용 - Data URI, PEM 파일, 이메일 MIME처럼 URL 안전성이 무관한 인라인 데이터.

Base64를 쓰면 안 되는 경우

• 비밀번호 저장 - Base64는 되돌릴 수 있는 인코딩이지 해시가 아닙니다. 비밀번호에는 bcrypt, scrypt, 또는 Argon2를 사용하세요.
• 어떤 형태의 기밀 보호도 불가 - 인코딩은 암호화가 아닙니다. 누구나 한 줄 코드로 디코딩할 수 있습니다. 전송 보안에는 TLS, 저장 보안에는 AES-GCM 등 암호화를 사용하세요.
• JSON 안의 대용량 이진 데이터 - Base64는 약 33%의 용량 오버헤드가 생깁니다. 수백 KB가 넘는 파일은 presigned URL, multipart form, 또는 이진 프레이밍(gRPC, Protobuf)을 고려하세요.
• 코드 난독화 - 보안 스캐너, WAF, 브라우저 개발자도구는 Base64를 자동으로 디코딩합니다. 일반 독자를 잠깐 늦출 뿐 공격자에게는 아무 의미가 없습니다.

디코딩 오류 해결 방법

• "유효하지 않은 문자" 오류 - 공백, 줄바꿈, 스마트 따옴표가 포함된 경우입니다. 본 도구는 공백을 자동 제거하지만, Word나 Slack에서 붙여넣으면 U+00A0(Non-breaking Space)이 섞일 수 있습니다. 의심되는 문자를 직접 다시 입력하세요.
• 결과가 깨진 바이트 같습니다 - 이진 데이터(이미지, PDF, 압축 파일)를 디코딩한 것입니다. 텍스트로 보는 대신 파일 모드로 전환해 다운로드 버튼을 사용하세요.
• 길이가 4의 배수가 아닙니다 - Base64URL에서 패딩이 생략된 경우입니다. 길이가 4의 배수가 될 때까지 =를 붙이거나, 패딩 없이도 동작하는 디코더를 사용하세요. 본 도구는 두 경우 모두 자동으로 처리합니다.
• JWT에서 "잘못된 패딩" 오류 - JWT 스펙상 각 세그먼트는 = 패딩을 생략합니다. 엄격한 Base64 디코더에 전달하기 전에 항상 패딩을 추가하세요.
• 유니코드 텍스트가 왕복 후 깨집니다 - 브라우저 내장 atob()/btoa()는 바이트 단위로 동작해 멀티바이트 UTF-8을 처리하지 못합니다. 이 페이지는 내부적으로 TextEncoder/TextDecoder를 사용하므로 이모지와 한글 같은 비라틴 문자도 정확하게 왕복 처리됩니다.

개발자를 위한 성능 참고

인코딩ㆍ디코딩은 O(n) 연산으로 매우 빠릅니다. 최신 노트북 기준으로 1MB 파일 인코딩은 약 1밀리초 정도면 끝납니다. 실질적인 비용은 33%의 용량 증가와, 원본 이진 데이터에 비해 압축 효율이 낮다는 점입니다(Base64 알파벳은 압축 알고리즘이 의존하는 저빈도 바이트를 포함하지 않기 때문). 이진 데이터 크기가 성능에 영향을 줄 만큼 크다면 Base64를 건너뛰고 이진 전송 방식을 사용하세요.

API 페이로드에 JSON을 다룰 때는 JSON 포매터ㆍ변환기로 구조를 정리하세요. 리소스 식별자로 Base64보다 충돌 위험이 낮은 UUID가 필요하다면 UUID 생성기를 활용하세요.

자주 묻는 질문

Base64는 암호화인가요?

아닙니다. 단순한 인코딩이며 누구나 쉽게 디코딩할 수 있습니다. 비밀번호 보호 용도로는 사용하지 마세요.

파일 크기는 얼마나 커지나요?

Base64 인코딩 후에는 약 33% 정도 크기가 증가합니다.

URL이나 파일명에 Base64를 그대로 써도 되나요?

표준 Base64는 `+`ㆍ`/`ㆍ`=` 문자를 포함해 URL 문법과 충돌할 수 있습니다. URL에는 `+`를 `-`로, `/`를 `_`로 치환한 URL-safe Base64(Base64URL)를 사용하세요.