Base64 인코딩·디코딩

Base64 Encoder & Decoder

텍스트와 파일을 Base64·Base64URL로 인코딩·디코딩하며 UTF-8을 올바르게 처리합니다.

텍스트나 파일 전체를 Base64로 만들고 다시 되돌립니다. data: URI도, JWT가 쓰는 URL-safe 알파벳도 함께 다룹니다. 텍스트는 먼저 UTF-8을 거치는데, 브라우저에 들어 있는 `btoa`가 아예 못 하는 부분이 그것입니다.

🔒 브라우저 안에서만 처리base64encodedecode

모드

알파벳

MIME에서 쓰는 +/ 알파벳.

패딩끝에 붙는 = 기호. JWT는 떼고 씁니다.

76자에서 줄바꿈MIME 줄 길이.

텍스트 또는 파일 입력

아무 파일이나 놓기

이 탭에서 읽습니다. 올라가지 않습니다.

Base64 출력

텍스트는 Base64로 만들기 전에 UTF-8로 인코딩합니다. 그래서 한글과 이모지가 왕복해도 살아남습니다. 브라우저에 있는 btoa 는 U+00FF를 넘는 글자를 그냥 거부해서 이 일을 못 합니다. 그래서 인코더를 가져다 쓰지 않고 직접 썼습니다.

사용 방법

가진 것을 입력하거나 놓습니다
입력 상자에는 아무 텍스트나, 아래 영역에는 아무 파일이나 넣을 수 있습니다. 파일은 조각으로 나눠 인코딩하니 큰 파일이라도 탭이 멈추지 않습니다. 인코딩 모드에서 이미 Base64로 보이는 것을 붙여넣으면 모드를 바꿀지 물어봅니다.
알파벳을 고릅니다
Base64는 MIME의 `+/` 알파벳입니다. Base64URL은 `-_` 알파벳으로, URL 경로나 JWT 조각에 들어가는 쪽입니다. 서로 바꿔 쓸 수 없습니다. 한쪽 디코더는 다른 쪽을 거절합니다.
패딩과 줄바꿈을 정합니다
끝의 `=`는 어떤 파서에는 필수이고 JWT에서는 빼야 합니다. 76자 줄바꿈은 MIME 줄 길이라서, 출력이 이메일 헤더나 PEM 모양 파일로 갈 때만 의미가 있습니다.
data URI가 필요했다면 그것을 가져갑니다
파일을 놓으면 MIME 타입이 붙은 `data:` URI도 함께 나오고, 원본보다 얼마나 커졌는지 보여 줍니다. 대략 3분의 1인데, 인라인으로 넣을지 말지는 그 숫자로 정합니다.

자주 묻는 질문

다른 데서는 깨지는 한글이 여기서는 왜 멀쩡한가요?

Base64로 만들기 전에 텍스트를 UTF-8 바이트로 바꾸기 때문입니다. 브라우저의 `btoa`는 U+00FF를 넘는 글자에서 예외를 던지고, 흔한 우회책인 `unescape(encodeURIComponent(…))`는 많은 사이트가 쓰면서 조용히 틀리는 방법입니다. 둘 다 피하려고 인코더를 직접 썼습니다.