Base64 인코더·디코더는 텍스트를 RFC 4648에 정의된 64개 ASCII 문자로 바꾸고 다시 원래대로 되돌립니다. 입력은 먼저 UTF-8 바이트로 변환되므로 한글, 악센트 문자, 이모지도 깨지지 않습니다. 브라우저의 btoa()를 그대로 쓰면 이런 문자에서 오류가 나는데, 이 도구는 그 문제를 피합니다.
토큰의 가운데 부분을 읽거나, Basic 인증 헤더에 무엇이 들어 있는지 확인하거나, JSON·YAML 설정에 넣을 값을 만들거나, URL이나 파일명에 퍼센트 이스케이프 없이 넣을 Base64URL 문자열이 필요할 때 씁니다. 스위치로 인코딩 결과를 URL 안전 알파벳으로 바꿀 수 있고, 디코딩은 두 알파벳은 물론 data:...;base64, URI 전체도 자동으로 인식합니다. 입력하는 즉시 결과가 갱신되며, 파일 모드는 최대 8MiB의 이미지나 파일을 읽어 Base64, data URI, CSS url() 값, HTML <img> 태그로 만들어 줍니다.
계산은 모두 브라우저 탭 안에서 이루어지며, 입력한 텍스트는 이 도구가 서버로 전송하지 않습니다. Base64는 암호화가 아니라 인코딩이므로, 여기서 풀리는 값은 처음부터 보호되어 있지 않았던 값입니다.
사용 방법
텍스트 또는 Base64 문자열 붙여넣기
인코딩하려면 일반 텍스트를, 디코딩하려면 Base64 또는 Base64URL 문자열을 입력창에 넣습니다. 디코딩할 때 앞뒤 공백은 무시되고, 중간의 줄바꿈과 탭은 지운 뒤 디코딩합니다.
인코딩 알파벳 선택
URL 안전 옵션을 끄면
+,/,=패딩을 쓰는 표준 Base64가, 켜면-,_를 쓰고 패딩이 없는 Base64URL이 만들어집니다.인코딩 또는 디코딩 선택
인코딩은 텍스트를 UTF-8 바이트로 바꾼 뒤 Base64로 변환하며 입력하는 즉시 결과가 갱신됩니다. 디코딩은 그 반대이며 data URI도 받습니다. Base64 문자가 아니면 원인을 알려 주는 오류가 표시되고, 바이트가 올바른 UTF-8이 아니면 그 사실을 알리고 바이트를 내려받게 해 줍니다.
결과 복사 또는 내려받기
결과를 클립보드에 복사하거나 텍스트 파일로 저장합니다. 텍스트 한도는 UTF-8 기준 64KiB입니다. 그보다 크거나 바이너리인 데이터는 파일 모드를 쓰세요. 최대 8MiB까지 처리하며 파일을 업로드하지 않습니다.
파일 인코딩
입력 방식을 파일로 바꾸고 파일을 끌어다 놓습니다. Base64, Data URI, CSS url(), HTML img 탭 중에서 골라 복사하거나 내려받습니다. 이미지는 미리보기도 나오고, URL 안전 스위치는 Base64 탭에 적용됩니다.
작동 원리
Base64가 바이트를 문자로 바꾸는 방식
Base64는 입력을 3바이트(24비트)씩 읽어 6비트 단위 네 개로 나눕니다. 각 값은 0부터 63까지의 번호이며 A-Z, a-z, 0-9, +, / 순서의 알파벳에서 문자 하나를 고릅니다. Man의 세 바이트 0x4D 0x61 0x6E은 이진수로 010011 010110 000101 101110이고, 번호로는 19, 22, 5, 46이므로 TWFu가 됩니다.
입력 길이가 3의 배수가 아니면 마지막 묶음을 0 비트로 채우고, 출력 길이가 4의 배수가 되도록 =를 덧붙입니다. 따라서 인코딩 결과의 길이는 4 x ceil(n / 3)자이며 원본보다 약 33퍼센트 커집니다.
Man -> 0x4D 0x61 0x6E
-> 010011 010110 000101 101110
-> 19 22 5 46
-> T W F u표준 Base64와 Base64URL (RFC 4648 4절·5절)
표준 알파벳에는 URL과 파일 경로에서 특별한 의미를 가지는 +와 /가 들어 있습니다. RFC 4648 5절은 이 둘을 -와 _로 바꾼 URL·파일명 안전 방식을 정의하며, 길이로 복원할 수 있으므로 = 패딩은 보통 생략합니다. JSON Web Token의 세 구간은 모두 이 패딩 없는 Base64URL입니다.
| 항목 | 표준 (4절) | URL 안전 (5절) |
|---|---|---|
| 62번 / 63번 문자 | + / / | - / _ |
| 패딩 | =로 4의 배수 맞춤 | 보통 생략 |
| 주로 쓰이는 곳 | MIME 메일, data URI, PEM 본문 | JWT, URL, 파일명, 쿠키 |
| URL 쿼리에 이스케이프 없이 사용 | 불가 | 가능 |
UTF-8이 중요한 이유
Base64가 인코딩하는 대상은 문자가 아니라 바이트입니다. 브라우저의 btoa()는 U+00FF까지의 문자만 받기 때문에 안녕은 바이트로 먼저 바꾸지 않으면 오류가 납니다. 이 도구는 UTF-8(RFC 3629)로 변환하므로 안녕 🌱은 11바이트가 된 뒤에 Base64가 적용됩니다. 디코딩은 엄격한 UTF-8 디코더를 쓰기 때문에, UTF-16 바이트 순서 표시인 FF FE처럼 올바른 UTF-8이 아닌 바이트는 대체 문자로 바꾸지 않고 텍스트가 아니라고 알려 줍니다.
실제 예시
Hello, local browser!SGVsbG8sIGxvY2FsIGJyb3dzZXIh입력이 21바이트로 3의 배수라서 = 패딩이 붙지 않습니다. URL 안전 옵션을 켜도 결과는 같습니다.
안녕 🌱7JWI64WVIPCfjLE=UTF-8로 11바이트입니다. URL 안전 옵션을 켜면 패딩이 빠진 7JWI64WVIPCfjLE가 나옵니다.
hi>>?표준: aGk+Pj8=
URL 안전: aGk-Pj8표준의 +는 -로 바뀌고 패딩이 사라집니다. ???는 Pz8/와 Pz8_가 됩니다.
SGVsbG8Hello빠진 = 패딩은 자동으로 보충되므로 토큰에서 가져온 Base64URL 문자열을 그대로 풀 수 있습니다.
//4=텍스트 아님: 2바이트가 디코딩됨 (내려받기 제공)디코딩된 바이트는 FF FE로 올바른 UTF-8이 아닙니다. 텍스트는 표시하지 않지만 바이트를 내려받을 수 있습니다. 패딩이 올바른 표준 Base64 이미지 data URI는 미리보기도 나옵니다.
hi.txt (2바이트, text/plain)Base64: SGk=
URL 안전: SGk
Data URI: data:text/plain;base64,SGk=파일 모드는 어떤 파일이든 같은 네 개의 탭을 만듭니다. data URI는 항상 패딩이 있는 표준 Base64를 씁니다.
자주 하는 실수
Base64는 암호화가 아닙니다
누구나 한 번에 디코딩할 수 있습니다. 비밀번호나 API 키를 Base64로 바꿔 두면 얼핏 보이지 않을 뿐 보호되는 것은 아닙니다.
줄바꿈이 들어간 Base64는 되지만 중간 공백은 안 됩니다
메일(MIME)과 PEM 형식은 76자 또는 64자마다 줄을 바꿉니다. 이 디코더는 줄바꿈과 탭을 지운 뒤 디코딩하므로 그런 블록을 그대로 붙여넣어도 됩니다. 문자열 중간의 공백은 여전히 거부합니다. URL이나 폼 디코딩으로
+가 공백이 된 경우가 많아서, 공백을 그냥 지우면 엉뚱한 바이트가 나오기 때문입니다. 잘못된 Base64라는 오류가 나면 공백을+로 바꿔서 다시 시도해 보세요.+가 공백으로 바뀌는 문제표준 Base64가 URL 쿼리나 폼 본문을 거치면
+가 공백으로 읽혀 데이터가 깨질 수 있습니다. URL 안전 옵션을 쓰거나 값을 퍼센트 인코딩하세요.바이너리는 텍스트로 표시되지 않습니다
텍스트 결과에는 올바른 UTF-8만 나옵니다. 이미지, PDF, gzip을 Base64로 만든 값은 다른 바이트로 디코딩되므로 텍스트가 아니라고 알려 줍니다. Base64 자체는 올바르니 바이트를 내려받거나, 이미지를 패딩이 올바른 표준 Base64 data URI로 붙여넣어 미리보기를 확인하세요.
크기 증가와 한도
Base64는 데이터를 약 3분의 1 키우므로 큰 이미지를 data URI로 쓰는 것은 비효율적입니다. 텍스트 입력은 UTF-8 기준 64KiB, 파일은 8MiB로 제한됩니다. 원본 파일이 아니라 붙여넣을 텍스트의 크기를 확인하세요.
자주 묻는 질문
Base64로 비밀번호를 숨겨도 되나요?
안 됩니다. 알파벳이 공개되어 있고 키도 없는 되돌릴 수 있는 인코딩입니다. 제대로 된 암호화를 쓰거나, 비밀 값을 저장하지 않는 쪽이 낫습니다.
Base64와 Base64URL은 무엇이 다른가요?
Base64URL은 +를 -로, /를 _로 바꾸고 보통 = 패딩을 생략해 URL과 파일명에 쓸 수 있게 한 방식입니다. 그 외 알고리즘은 같습니다.
Base64 문자열 끝에 =나 ==가 붙는 이유는 무엇인가요?
마지막 묶음을 4글자로 맞추는 패딩입니다. = 하나는 마지막 묶음의 입력이 2바이트였다는 뜻이고, ==는 1바이트였다는 뜻입니다.
JWT도 이 도구로 풀 수 있나요?
JWT의 각 구간은 Base64URL로 인코딩된 JSON이라서 한 구간씩 붙여넣어 풀 수 있습니다. 이 사이트의 JWT 디코더는 세 구간을 나누고 클레임을 보기 좋게 정리해 줍니다.
이미지나 파일을 data URI로 만들 수 있나요?
됩니다. 파일 모드로 바꾸고 파일(최대 8MiB)을 끌어다 놓으면 Base64, 전체 data: URI, CSS url() 선언, HTML <img> 태그가 만들어집니다. 파일은 브라우저 안에서 읽으며 업로드되지 않습니다.
한글이나 이모지도 인코딩되나요?
됩니다. 텍스트를 먼저 UTF-8 바이트로 바꾸므로 한글, 일본어, 악센트 문자, 이모지도 오류 없이 인코딩과 디코딩이 됩니다.
입력한 텍스트가 서버로 전송되나요?
입력은 브라우저 안에서 처리되며 이 도구가 서버로 전송하지 않습니다. 다만 어떤 웹 페이지든 실제 운영 환경의 자격 증명은 붙여넣지 않는 편이 좋습니다.
더 깊이 읽기
- 7분 읽기Base64란 무엇인가: 비트 단위 인코딩 원리, 패딩, Base64URL, data: URI까지Base64는 바이트를 6비트 조각으로 다시 자르는 고정된 규칙으로, 바이너리를 텍스트 전용 통로에 실어 보내기 위한 것입니다. 비트 배치를 한 번 보고 나면 패딩, 크기 증가, URL 안전 변형이 모두 거기서 따라 나옵니다.
- 10분 읽기JWT 구조와 안전한 디코딩: 헤더, 페이로드, 서명, 그리고 디코딩이 증명하지 못하는 것JSON Web Token은 점으로 이은 Base64URL 문자열 세 개입니다. 읽는 데는 몇 초면 되지만, 믿으려면 검증된 서명과 몇 가지 클레임 검사가 필요합니다.
마지막 업데이트: