Base64 인코딩·디코딩 3단계
- 인코딩 또는 디코딩을 선택합니다.
- 인코딩할 원문이나 디코딩할 Base64 문자열을 붙여 넣습니다. 한글과 이모지는 UTF-8로 처리됩니다.
- URL·파일명에 넣을 때만 URL-safe를 선택하고, 상대 규격이 허용할 때만
=패딩을 생략합니다.
입력과 결과는 이 브라우저 안에서 계산되며 Tranfox 서버로 업로드하지 않습니다. 민감정보는 Base64 자체로 보호되지 않으므로 결과를 공개 채널에 공유하지 마세요.
표준 Base64와 URL-safe Base64 비교
| 구분 | 62·63번째 문자 | 패딩 | 주요 환경 |
|---|---|---|---|
| 표준 Base64 | +, / | 기본적으로 = 사용 | 일반 데이터 전송, 문서에 명시된 Base64 |
| URL-safe(Base64url) | -, _ | 규격이 허용하면 생략 가능 | URL, 파일명, JWT 세그먼트 |
RFC 4648 표준 Base64와 URL·파일명 안전 알파벳은 두 형식을 별도 이름으로 구분합니다. 받는 API나 라이브러리 문서가 어느 형식을 요구하는지 먼저 확인하세요.
한글이 깨지지 않게 변환하는 기준
Base64는 문자를 직접 인코딩하지 않고 바이트를 인코딩합니다. 같은 한글도 UTF-8, UTF-16, EUC-KR 가운데 무엇으로 바이트화했는지에 따라 Base64 결과가 달라집니다. 이 도구는 브라우저의 TextEncoder로 UTF-8 바이트를 만들고, 디코딩할 때 TextDecoder의 엄격 모드로 유효한 UTF-8인지 검사합니다.
줄바꿈된 이메일·로그 값을 붙여 넣을 수 있도록 공백은 제거하지만, Base64 알파벳 밖의 문자는 오류로 표시합니다. RFC 4648은 별도 규격이 허용하지 않는 한 알파벳 밖 문자를 거부하도록 정하므로 임의의 기호를 조용히 무시하지 않습니다.
= 패딩은 언제 필요한가요?
Base64는 입력 3바이트를 출력 4문자로 표현합니다. 마지막 묶음이 3바이트보다 짧으면 =로 길이를 맞춥니다. RFC 4648의 기본은 패딩 포함이며, 데이터 길이를 다른 방식으로 아는 규격이 명시적으로 허용할 때만 생략할 수 있습니다. 일반 API 입력은 패딩을 유지하고, JWT처럼 Base64url 무패딩을 요구하는 경우에만 생략하세요.
Base64는 암호화가 아닙니다
Base64 인코딩 결과는 비밀키 없이 즉시 원문으로 되돌릴 수 있습니다. 검색에서 흔히 쓰는 Base64 복호화는 편의 표현일 뿐 정확한 작업명은 디코딩입니다. 비밀번호, API 키, 개인정보를 Base64로 바꿔 저장하거나 전송해도 기밀성이 생기지 않습니다. 보안이 필요하면 전송 구간의 HTTPS, 검증된 암호화 방식, 비밀 관리 도구를 별도로 사용해야 합니다.
JWT·Basic 인증에서 주의할 점
- JWT: 점으로 나뉜 header와 payload는 보통 Base64url이지만, 읽어 보는 것만으로 서명이 검증되지는 않습니다.
- HTTP Basic: 사용자명과 비밀번호를 Base64로 표현할 뿐이므로 반드시 HTTPS 위에서 사용해야 합니다.
- Data URL: 이 도구는 UTF-8 텍스트용입니다. 이미지·PDF 같은 바이너리를 텍스트로 억지 디코딩하면 오류가 납니다.
입력 오류가 날 때 확인할 항목
data:image/...;base64,같은 접두사를 함께 넣지 않았는지 확인합니다.- 표준 문자
+ /와 URL-safe 문자- _가 섞이지 않았는지 봅니다. =가 문자열 중간에 있거나 세 개 이상 붙지 않았는지 확인합니다.- 결과가 파일 바이트라면 텍스트 전용 도구 대신 해당 파일 형식을 지원하는 도구를 사용합니다.
표준 확인: IETF RFC 4648, WHATWG HTML의 atob·btoa 정의 · 최종 검수 2026-07-26