Base64 인코딩·디코딩 변환기 — 텍스트·파일·이미지 변환
Base64 인코딩과 디코딩을 온라인에서 처리할 수 있습니다. 텍스트 문자열은 물론 파일을 직접 업로드하여 변환할 수 있습니다.
이미지 파일을 인코딩하면 data:image/...;base64, 형식의 Data URI 문자열이 생성됩니다.
이 값을 HTML의 <img src="..."> 태그나 CSS 파일에 직접 삽입하면 외부 HTTP 요청 없이 이미지를 표시할 수 있습니다.
디코딩 시에는 Standard, URL-safe, MIME 형식을 자동으로 감지합니다.
문자셋은 UTF-8, EUC-KR, Shift_JIS, GBK, Big5 등 한국어·일본어·중국어를 포함한 20종 이상의 인코딩을 선택할 수 있습니다.
URL에 포함할 특수문자가 있다면 URL 인코딩 변환기를, 업로드할 이미지가 크다면 이미지 압축기를 먼저 사용해 보세요.
Base64 변환 결과가 예상과 다를 때 확인할 것들
변환 결과가 비어 있거나 깨진 문자로 나온다면 문자셋 설정을 먼저 확인하세요.
인코딩 당시 사용한 문자셋과 디코딩 시 선택한 문자셋이 달라지면 한국어, 일본어 등 멀티바이트 문자가 정상 출력되지 않습니다.
입력값에 공백이나 줄바꿈이 섞여 있는 경우에는 "앞뒤 공백 제거"와 "공백·줄바꿈·탭 무시" 옵션을 켜고 다시 시도해 보세요.
긴 바이너리 데이터는 파일 업로드 방식으로 처리하는 편이 안정적입니다.
Base64 인코딩이 실제 개발에서 쓰이는 곳
웹 개발 실무에서 Base64를 마주치는 상황은 생각보다 많습니다.
JWT 토큰의 헤더와 페이로드는 URL-safe Base64로 인코딩되어 있습니다.
REST API 응답에서 바이너리 파일을 JSON 안에 담을 때도 Base64 문자열로 변환해 전달하는 방식이 흔합니다.
이메일 첨부파일은 MIME 표준에 따라 Base64로 인코딩된 뒤 전송됩니다. 또한 일부 데이터베이스 시스템은 BLOB 대신 Base64 텍스트로 바이너리 데이터를 저장하기도 합니다.
이 변환기에서 인코딩 결과를 직접 확인할 수 있습니다.
파일 크기와 Base64 인코딩 용량 증가
Base64로 인코딩하면 원본보다 약 33% 용량이 늘어납니다.
8비트 데이터를 6비트 단위로 쪼개 64가지 문자로 표현하는 방식이기 때문입니다.
작은 아이콘이나 인라인 이미지처럼 크기가 작은 파일은 Base64로 코드에 직접 포함하는 것이 편리합니다.
반면 고해상도 사진이나 영상처럼 용량이 큰 파일을 Base64로 처리하면 네트워크 전송량이 크게 늘어납니다.
대용량 파일은 일반 URL 참조 방식을 유지하는 편이 낫습니다.
Base64 복호화 — 어떤 문자열을 붙여 넣어야 하나요?
API 응답, 이메일 원문, JWT 토큰 등에서 Base64로 인코딩된 문자열을 마주치는 경우가 있습니다.
복호화 탭에 해당 문자열을 붙여 넣으면 원본 텍스트나 바이너리 데이터로 되돌릴 수 있습니다.
Padding(=)이 제거된 채 전달된 문자열도 Padding 자동 보정 기능으로 처리됩니다.
결과가 의도한 텍스트가 아닌 경우, 올바른 문자셋을 선택했는지 확인하세요. 문자셋 선택이 맞지 않으면 한국어나 특수문자가 깨져 보일 수 있습니다.
Base64와 다른 인코딩 방식 비교
Base64, URL 인코딩, Hex 인코딩은 모두 데이터를 텍스트로 변환하지만 목적과 결과가 다릅니다.
Hex 인코딩은 1바이트를 2자리 16진수로 표현해 가독성이 높지만 크기가 두 배로 늘어납니다.
Base64는 Hex보다 압축률이 높아 같은 데이터를 더 짧은 문자열로 표현합니다.
URL 인코딩은 URL에 허용되지 않는 특수문자를 %XX 형식으로 치환하는 방식으로, 바이너리 전체를 텍스트로 옮기기보다는 URL 구성에 특화되어 있습니다.
용도에 맞는 방식을 선택하는 것이 중요합니다.
자주 묻는 질문
Standard Base64는 +와 / 문자를 사용합니다.
이 문자들은 URL에서 다른 의미로 해석되기 때문에 URL 파라미터에 그대로 포함하면 값이 깨질 수 있습니다.
URL-safe Base64는 +를 -로, /를 _로 대체한 방식입니다.
JWT 토큰, OAuth 인증값 등에서 주로 사용됩니다.
- URL 파라미터에 Base64 값을 넣을 때는 URL-safe 옵션을 선택하세요.
- 이 변환기는 디코딩 시 두 방식을 자동으로 감지합니다.
이미지를 Base64로 인코딩하면 Data URI 형식의 문자열이 생성됩니다.
이 문자열을 코드에 직접 삽입해 외부 파일 없이 이미지를 표시할 수 있습니다.
- HTML:
<img src="data:image/png;base64,..."> - CSS:
background-image: url("data:image/...") - 이메일 템플릿: 외부 이미지 차단 환경에서도 이미지 표시 가능
파일 크기가 커지므로 아이콘이나 소형 이미지에 적합합니다. 큰 이미지는 이미지 압축기로 먼저 줄인 뒤 변환하세요.
Base64는 암호화가 아닙니다. 바이너리 데이터를 텍스트로 표현하는 인코딩 방식일 뿐, 보안 기능은 없습니다.
누구나 Base64 디코딩으로 원본 데이터를 복원할 수 있으므로 비밀번호, 개인정보, 인증 토큰 등을 Base64만으로 보호해서는 안 됩니다.
- 데이터 보호가 목적이라면 AES, RSA 같은 암호화 알고리즘을 사용하세요.
- Base64는 암호화 결과를 텍스트로 안전하게 전달할 때 보조 수단으로 사용됩니다.
파일 디코딩 탭에서 Base64 문자열을 붙여 넣고 디코딩하면 다운로드 버튼이 나타납니다.
버튼을 눌러 원본 파일로 저장하세요.
이미지 파일의 경우 다운로드 전에 화면에서 미리볼 수 있습니다.
MIME Base64는 이메일 전송 표준(RFC 2045)에서 정의한 방식으로, Base64 문자열을 76자마다 줄바꿈하여 출력합니다.
일부 이메일 서버는 줄바꿈 없이 긴 문자열을 처리하지 못합니다.
이메일 첨부파일이나 SMTP 관련 작업을 처리할 때 MIME 옵션을 선택하세요.
디코딩 시에는 자동 감지 모드가 MIME 형식을 인식하므로 별도로 선택하지 않아도 됩니다.
Base64는 바이너리 데이터를 영문자·숫자·기호(총 64가지 문자)로 표현하는 인코딩 표준입니다.
텍스트만 처리할 수 있는 환경에서 이미지, 파일, 오디오 같은 바이너리 데이터를 안전하게 전달하기 위해 사용합니다.
- 이메일 첨부파일 (MIME 표준).
- HTML/CSS의 Data URI 이미지 삽입.
- API 통신 — JSON·XML 응답 내 바이너리 데이터 전달.
- JWT 토큰 페이로드 인코딩.
IETF RFC 4648을 기반으로 한 국제 표준이며, 오늘날 거의 모든 개발 환경에서 사용됩니다.
Base64는 3바이트(24비트)를 4문자로 변환합니다.
입력 데이터가 3의 배수가 아닐 경우 남는 자리를 = 또는 ==으로 채웁니다. 이것이 Padding입니다.
일부 시스템은 Padding 없이 Base64를 전달하기도 합니다.
이 변환기의 Padding 자동 보정 기능은 Padding이 없는 문자열도 정상적으로 디코딩합니다.
직접 Padding을 제거하고 싶다면 인코딩 옵션에서 "Padding 제거 (=)"를 선택하세요.