Base64 인코딩·디코딩

사용 방법

1. 인코딩은 텍스트나 파일을 Base64로, 디코딩은 Base64를 다시 텍스트나 파일로 바꿉니다. 위에서 모드를 고르세요.
2. 텍스트, 완전한 data: URI 또는 파일을 붙여넣거나 끌어다 놓으세요. 최대 20만 자까지는 이 브라우저에만 저장되어 새로고침해도 남아 있습니다.
3. 인코딩할 때는 표준(+/) 또는 URL-safe(-_) 출력을 고르고, 패딩(=) 포함 여부를 켜고 끌 수 있습니다.
4. 디코딩은 표준과 URL-safe Base64를 자동으로 구분해 처리하므로, 줄바꿈이 섞여 있거나 두 방식이 섞여 있어도 그대로 디코딩됩니다.
5. 결과는 복사하거나 .txt(인코딩) 또는 디코딩된 파일로 저장할 수 있습니다.
6. 탭이 멈추지 않도록 텍스트·파일 인코딩은 8MB, Base64 디코딩 입력은 12MB까지 사용하세요.

표준 Base64와 URL-safe Base64의 차이

RFC 4648은 두 가지 Base64 알파벳을 정의합니다. 표준 Base64(4장)는 마지막 두 글자로 +와 /를 쓰며 이메일(MIME)과 data: URI에서 흔히 쓰입니다. URL-safe Base64(5장, base64url)는 이 두 글자를 -와 _로 바꿔서 URL 경로, 쿼리 문자열, 파일명, JWT(JSON Web Token)에 퍼센트 인코딩 없이 그대로 넣을 수 있게 합니다.

끝에 붙는 =패딩은 선택 사항이며, URL에서 =가 특별한 의미를 가질 수 있어 JWT 등에서는 보통 생략합니다. 이 도구는 인코딩할 때 두 알파벳 중 하나를 고를 수 있고, 디코딩할 때는 어느 쪽인지 묻지 않고 섞여 있어도 그대로 처리합니다.

왜 디코딩이 조용히 실패하지 않을까

Base64 입력이 잘못되는 경우는 몇 가지로 정해져 있습니다. 64개 알파벳(및 URL-safe의 -, _)에 없는 문자가 섞였거나, '=' 패딩 형식이 맞지 않거나, 한 글자가 남아 6비트로는 1바이트조차 만들 수 없는 길이이거나, 마지막 글자의 사용하지 않는 비트가 0이 아닌 경우입니다. 마지막 규칙은 서로 다른 문자열이 같은 바이트로 조용히 디코딩되는 일을 막습니다.

많은 온라인 디코더는 그냥 '잘못된 입력'이라고만 말하거나, 조용히 깨진 바이트를 돌려줍니다. 이 도구는 각 경우를 구분해 어떤 글자가 몇 번째 위치에서 문제인지 알려주고, 디코딩된 바이트가 UTF-8 텍스트로 읽을 수 없을 때도 명확히 알려줘서 파일로 내려받아야 한다는 걸 바로 알 수 있습니다.

텍스트뿐 아니라 파일도

인코딩 중 파일을 끌어다 놓으면 이미지뿐 아니라 어떤 종류의 파일이든 원본 바이트를 그대로 읽어 Base64로 바꿉니다. data: URI나 이메일 첨부파일이 내부적으로 쓰는 방식과 같습니다. `data:…;base64,…` 형태의 완전한 data: URI를 붙여넣어 헤더를 제외한 Base64 본문만 디코딩할 수도 있습니다.

디코딩은 항상 바이트 그대로의 파일로 내려받을 수 있고, 그 바이트가 UTF-8 텍스트로도 유효하다면 화면에서 바로 읽고 복사할 수도 있습니다. 큰 결과 때문에 탭이 멈추지 않도록 인코딩 원본은 8MB, 디코딩 Base64 입력은 12MB로 제한합니다. 변환은 이 탭의 백그라운드 워커에서 브라우저 File·TextDecoder API로 이루어지며 서버로 전송되지 않습니다.

자주 묻는 질문