Base64 인코드 / 디코드
브라우저에서 Base64 변환을 즉시 실행. 크기 자동 계산 — 데이터 URI와 API 테스트에 유용.
다른 도구
📖 자주 걸리는 지점
텍스트나 파일을 Base64 로 변환하고 역변환도 합니다. URL-safe 형식과 구 MIME 형식의 76 자마다의 줄바꿈에도 대응합니다. 처리는 브라우저 안에서 끝납니다. Base64 는 바이트열을 ASCII 64 문자만으로 나타내기 위한 부호화이지 암호도 압축도 아닙니다 — 누구나 1 초면 되돌릴 수 있고 데이터양은 반드시 약 33% 늘어납니다. 이 두 가지를 잘못 안 데서 실무의 사고는 거의 전부 시작됩니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 일본어를 통과시키면 깨진다 · 예외가 난다 | Base64 가 다루는 것은 바이트열이지 문자가 아닙니다. 문자를 바이트로 고치는 단계 — 즉 문자 코드의 결정 — 는 Base64 의 바깥에서 이루어지며 여기가 보내는 쪽과 받는 쪽에서 어긋나면 깨집니다. 브라우저의 btoa() 는 Latin-1 범위밖에 받지 않으므로 일본어를 넘기면 InvalidCharacterError 로 예외가 납니다. 한편 PHP 의 base64_encode() 는 넘겨진 바이트열을 그대로 부호화하므로 원본이 Shift-JIS 라면 그 Shift-JIS 가 들어갑니다 — 에러가 나지 않는 만큼 이쪽이 더 까다롭습니다. |
Base64 로 만들기 전에 UTF-8 바이트열로 변환하세요. JavaScript 라면 new TextEncoder().encode(str) 로 Uint8Array 를 만든 뒤 부호화하고 복호 쪽은 new TextDecoder().decode(bytes) 로 되돌립니다. 이 왕복이 대칭이라면 어느 언어 사이에서도 깨지지 않습니다. 데이터를 외부와 주고받는 경우에는 Base64 의 내용이 UTF-8 이라는 것을 API 문서에 명기하세요 — Base64 문자열 자체에서는 문자 코드를 판별할 수 없으므로 받는 쪽은 쓰여 있지 않으면 추측할 수밖에 없습니다. |
| URL 이나 쿼리에 넣으면 깨진다 | 표준 Base64 가 쓰는 + / = 는 어느 것이나 URL 안에서 다른 의미를 갖습니다. 특히 위험한 것이 + 로 쿼리 문자열에서는 공백으로 해석되므로 복호하면 값이 깨집니다. 까다로운 것은 증상이 확률적으로 보인다는 점 — 부호화 결과에 + 가 포함되는지는 입력에 달렸으므로 테스트에서는 통과했는데 프로덕션의 특정 데이터만 실패하는 형태로 나옵니다. / 는 경로 구분과 충돌하고 = 는 파라미터 대입과 충돌합니다. |
URL 에 실을 거라면 URL-safe 형식을 쓰세요 — + 를 - 로, / 를 _ 로 바꾸고 끝의 = 를 뺀 것입니다(RFC 4648 의 base64url). JWT 는 이 형식으로 규격화되어 있으므로 JWT 를 직접 조립할 때는 선택의 여지가 없습니다. 망설여지면 Base64 로 만든 것을 다시 URL 인코딩하지 말고 처음부터 URL-safe 를 고르세요 — 이중으로 인코딩하면 한쪽만 복호해 왜인지 %2B 가 남아 있는 상태가 되기 쉽습니다. 패딩의 = 는 빼도 복호할 수 있습니다(길이로 복원할 수 있으므로). |
| data URI 로 심었더니 오히려 느려졌다 | 요청이 줄어드는 것은 사실이지만 데이터는 33% 늘고 게다가 브라우저의 캐시가 듣지 않습니다. 이미지를 CSS 안에 심으면 그 CSS 자체가 비대해지고 CSS 는 그리기를 막으므로 첫 표시가 느려집니다. 10KB 의 이미지를 20 개 심으면 본래 20 개의 병렬 요청으로 끝났을 것이 266KB 의 거대한 렌더링 차단 자원으로 변합니다. 나아가 이미지를 하나 바꾸는 것만으로 CSS 전체의 캐시가 무효가 됩니다. HTTP/2 이후는 요청 수의 비용이 크게 낮아졌으므로 요청을 줄인다는 전제 자체가 낡았습니다. | data URI 는 몇 KB 까지의 작은 아이콘에 한정하세요. 그 이상은 평범하게 <img> 로 읽어들여 캐시와 반응형 이미지(srcset)의 혜택을 받는 편이 빠릅니다. SVG 를 심는다면 Base64 로 만들지 마세요 — SVG 는 텍스트이므로 encodeURIComponent 로 URL 인코딩하는 편이 Base64 보다 작고 gzip 도 듣습니다. 판단 기준은 단순해서 그 이미지를 교체하는 빈도와 그 CSS 를 배포하는 횟수를 비교하는 것입니다 — 로고처럼 좀처럼 바뀌지 않고 전 페이지에서 쓰는 것만이 심기에 적합합니다. |
Base64 는 난독화조차 아닙니다. 설정 파일에 password: cGFzc3dvcmQ= 라고 써도 그것은 한눈에 읽히지 않을 뿐 비밀이 되지는 않습니다. Kubernetes 의 Secret 이 바로 이 형식이며 그것은 암호화가 아니라 부호화입니다 — kubectl get secret -o yaml 의 출력을 본 사람은 누구나 복호할 수 있습니다(그래서 외부의 시크릿 관리나 암호화를 따로 조합합니다). GitHub 의 시크릿 스캔이나 각종 유출 탐지는 Base64 를 펼쳐 내용을 봅니다. 저장소에 넣으면 평범하게 검출됩니다. 뒤집어 말하면 Base64 로 해 두었으니 괜찮다고 판단한 곳은 거의 확실히 취약점입니다. 한 가지 더, 줄 바꿈의 취급에 주의하세요 — 전자 메일이나 PEM 형식에서는 64~76 자마다 줄바꿈이 들어가며 이 줄바꿈을 제거하지 않고 복호하면 에러가 되는 구현이 있습니다. 반대로 줄바꿈을 넣어야 할 장면에서 한 줄로 하면 받아들이지 않는 오래된 시스템도 있습니다.
📖 사용법
-
1
입력 붙여넣기인코딩할 텍스트 또는 디코딩할 Base64 문자열을 붙여넣습니다.
-
2
방향 전환"인코딩/디코딩" 버튼으로 전환합니다.
-
3
URL-safe 변형 선택URL이나 JWT에는 URL-safe를 선택하세요.
❓ 자주 묻는 질문
왜 Base64는 크기가 33% 증가하나요?
바이너리 파일도 가능한가요?
데이터가 전송되나요?
줄바꿈은 어떻게 처리되나요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.