MiServe DevTools

내 스티커

도구를 여기에 고정하세요. 이 브라우저에 저장됩니다.

Base64 인코더·디코더

텍스트나 파일을 Base64로 인코딩하고 다시 디코딩합니다. URL-safe 알파벳, 패딩 생략, MIME 줄바꿈을 지원합니다.

브라우저에서 실행됩니다. 붙여 넣은 내용은 업로드되지 않습니다.

이 도구에 대하여

Base64란

Base64는 임의의 바이트를 출력 가능한 ASCII 문자 64개, 즉 A–Z, a–z, 0–9, +, /로 표현합니다. 3바이트가 4개의 문자가 되며, 입력 길이가 3의 배수가 아니면 마지막 그룹을 =로 채웁니다(패딩). RFC 4648에 정의되어 있습니다.

Base64는 텍스트용으로 만들어진 채널로 바이너리 데이터를 보내기 위해 존재합니다. 이메일 첨부 파일, HTML과 CSS의 data: URI, JSON의 바이너리 필드, HTTP Authorization: Basic 헤더, 서명된 JWT의 세 부분이 그 예입니다.

Base64는 인코딩이지 암호화가 아닙니다. 누구나 디코딩할 수 있으므로 아무것도 숨겨 주지 않습니다.

자주 접하는 변형

URL-safe 알파벳은 +와 /를 -와 _로 바꾸므로, 값을 이스케이프 없이 URL이나 파일 이름에 넣을 수 있습니다. JWT는 이 알파벳을 쓰면서 패딩도 생략합니다.

MIME(RFC 2045)은 출력을 최대 76자 길이의 줄로 나눕니다. 데이터 URI는 data:image/png;base64,…처럼 페이로드 앞에 미디어 타입을 붙이며, URL-safe 알파벳이 아닌 표준 알파벳을 사용합니다.

디코딩할 때 이 도구는 두 알파벳을 모두 받아들이고, 패딩이 빠져 있거나 공백, 탭, 줄바꿈이 섞여 있어도 처리하며, data:…;base64, 접두사는 건너뜁니다. 알파벳에 속하지 않는 문자가 있으면 그 문자와 위치를 알려 줍니다.

텍스트, 바이트, 파일

Base64는 바이트를 인코딩하므로 텍스트는 먼저 바이트로 바꿔야 합니다. 이 도구는 오늘날 대부분의 시스템이 기대하는 인코딩인 UTF-8을 사용합니다. JavaScript 내장 함수 btoa()는 U+00FF까지의 문자만 받아들이고 그 밖의 문자에는 예외를 던집니다. 그래서 이모지를 그대로 btoa()에 넘기는 코드는 실패합니다. é 같은 문자는 예외가 발생하지 않지만, btoa()는 이를 UTF-8의 2바이트가 아니라 Latin-1의 1바이트로 인코딩합니다.

디코딩한 뒤에는 바이트가 제어 문자 없는 유효한 UTF-8 텍스트인지 확인합니다. 그렇지 않으면 그 사실을 알려 주고, 앞부분 바이트로 PNG, JPEG, GIF, WebP, PDF, ZIP 데이터를 알아보며, 바이트를 파일로 다운로드할 수 있게 합니다. 선택한 파일은 브라우저가 읽으며 기기 밖으로 나가지 않습니다.

자주 묻는 질문

Base64는 암호화의 일종인가요?

아니요. Base64는 키 없이 되돌릴 수 있는 인코딩이므로 누구나 디코딩할 수 있습니다. 비밀번호, 토큰, 개인 정보를 보호하는 데 사용하지 마세요.

Base64 출력이 입력보다 큰 이유는 무엇인가요?

Base64 문자 하나는 8비트가 아니라 6비트를 담기 때문에, 3바이트마다 4개의 문자가 필요합니다. 그래서 결과는 원본보다 약 3분의 1 커지고, 여기에 패딩과 줄바꿈이 더해집니다.

Base64와 base64url의 차이는 무엇인가요?

base64url은 RFC 4648의 5절에 정의된 변형입니다. +와 / 대신 -와 _를 사용하고 = 패딩을 생략하는 경우가 많아, URL과 파일 이름에 안전하게 쓸 수 있습니다. 데이터는 같고 이 문자들만 다릅니다. 이 도구는 둘 다 디코딩합니다.

인코딩하는 파일이 어딘가에 업로드되나요?

아니요. 파일은 브라우저가 읽고 사용자의 기기에서 인코딩합니다. 서버로 전송되지 않습니다.

인코딩의 다른 도구