Base64 인코더·디코더

Base64는 3바이트를 4글자로 바꿉니다

Base64 인코딩은 데이터를 바이트 3개(24비트)씩 묶고 6비트씩 넷으로 나눈 뒤, 0~63 번호를 A~Z, a~z, 0~9, +, / 64글자 가운데 하나로 적는 방식입니다. 그래서 바이트 3개는 언제나 글자 4개가 되고, 결과는 원본보다 약 33% 길어집니다. 한글은 먼저 UTF-8 바이트로 바뀌므로 '안녕하세요 👋'는 20바이트이고, Base64로는 끝에 = 하나가 붙은 28자 7JWI64WV7ZWY7IS47JqUIPCfkYs=가 됩니다. Base64는 암호화가 아니라서 누구나 그대로 되돌릴 수 있습니다.

위 도구는 원문 칸과 Base64 칸을 모두 고칠 수 있습니다. 원문을 고치면 인코딩하고, Base64 칸에 값을 붙여 넣으면 디코딩합니다. Authorization: Basic 헤더, 메일 제목의 =?EUC-KR?B?…?=, data: 주소, PEM 인증서, PowerShell -EncodedCommand처럼 포장된 값도 그대로 붙여 넣으면 포장을 벗겨 읽습니다. UTF-8로 읽히지 않는 바이트는 EUC-KR·UTF-16 같은 다른 인코딩이나 PNG·PDF 같은 파일로 가려냅니다. 판독 경로에는 변환 단계가, 묶음 레일과 돋보기에는 3바이트가 4글자로 바뀌는 자리가 나옵니다.

Base64를 직접 풀거나 만들어야 하는 상황

• HTTP Basic 인증 헤더를 확인할 때: RFC 7617은 아이디와 콜론(:), 비밀번호를 이어 붙인 뒤 Base64로 인코딩해 Authorization: Basic 뒤에 보내도록 정합니다. 예를 들어 admin:1234는 YWRtaW46MTIzNA==입니다. 반대로 말하면 이 헤더를 본 사람은 누구나 비밀번호를 읽을 수 있으므로, Basic 인증은 HTTPS 위에서만 써야 합니다.
• 메일 제목이 =?EUC-KR?B?…?=처럼 보일 때: 메일 머리글에는 ASCII 글자만 쓰기 때문에 한글 제목은 RFC 2047의 encoded-word로 적힙니다. 물음표 사이의 EUC-KR이나 UTF-8은 글자 인코딩이고, B는 Base64라는 표시입니다. 머리글 값을 통째로 붙여 넣으면 적힌 인코딩으로 풀어 줍니다.
• 설정 값이나 Kubernetes Secret을 읽을 때: Kubernetes Secret의 data 필드 값은 Base64로 인코딩한 문자열이어야 하고, 인코딩하고 싶지 않으면 stringData 필드를 씁니다. 꺼낸 값이 무엇인지 확인하거나 새 값을 넣을 Base64를 만들 때 씁니다.
• JSON에 이미지·PDF 같은 파일을 담을 때: 글만 받는 형식에 파일 바이트를 넣을 때 Base64가 흔히 쓰입니다. Base64 칸에 붙여 넣은 값이 글이 아니면 이 도구는 형식과 크기를 보여 주고 파일로 저장하게 합니다.
• JWT 내용을 볼 때: JWT를 점(.)으로 나눈 각 부분은 URL-safe 글자를 쓰고 끝의 =를 뺀 Base64url(RFC 7515)입니다. 헤더와 페이로드는 여기서도 풀리지만 서명은 확인하지 않습니다.
• PowerShell -EncodedCommand 값을 만들거나 확인할 때: PowerShell 설명서는 이 값이 UTF-16LE로 인코딩한 문자열의 Base64여야 한다고 적습니다. 같은 Get-Date라도 UTF-8로는 R2V0LURhdGU=, UTF-16LE로는 RwBlAHQALQBEAGEAdABlAA==로 전혀 다릅니다.
• 인증서·키 파일(PEM)을 다룰 때: -----BEGIN CERTIFICATE----- 사이의 본문은 Base64이고, RFC 7468에 따라 한 줄을 64자로 감쌉니다. 본문을 풀면 DER 형식의 바이트가 나옵니다.

쓰는 법

1. 인코딩: 원문 칸에 글을 넣거나, '파일 넣기'로 파일을 고릅니다. 원문 칸에 파일을 끌어다 놓거나 붙여 넣어도 됩니다. Base64 칸에 바로 결과가 나옵니다.
2. 디코딩: Base64 칸에 값을 붙여 넣습니다. 앞뒤에 따옴표나 헤더 이름이 붙어 있어도 됩니다. 원문 칸에 글이 나오고, 글이 아니면 형식과 크기를 적은 파일 카드가 나옵니다.
3. 모양 고르기: 조절판에서 표준(+ /)과 URL-safe(- _), = 붙임과 생략, 한 줄·76자·64자 줄 나눔을 고릅니다. 붙여 넣은 값의 모양은 조절판에 그대로 옮겨지므로, 풀어 낸 글을 고쳐도 같은 모양으로 다시 만들어집니다.
4. 글자 인코딩: 기본값은 자동 판별입니다. 풀어 낸 글이 이상하면 UTF-8, UTF-16LE, EUC-KR 같은 인코딩을 직접 고릅니다. 한 줄에 값 하나씩 여러 값이 들어 있으면 '줄마다 따로'를 켭니다.
5. 확인: 판독 경로에서 벗긴 포장, 무시한 공백, 보충한 패딩을 확인합니다. 레일의 묶음을 누르면 돋보기에 그 묶음의 비트가 나옵니다. 다른 도구와 결과가 다르면 '같은 글, 다른 Base64' 목록에서 원인을 찾고, 줄을 누르면 그 값을 복사합니다.

3바이트가 4글자가 되는 규칙

'안'의 UTF-8 바이트 EC 95 88을 예로 들어 보겠습니다. 세 바이트를 이으면 24비트가 되고, 이것을 6비트씩 끊으면 0~63 사이 번호가 넷 나옵니다. 번호를 아래 글자표에서 찾아 적으면 7JWI가 됩니다.

데이터 끝이 3바이트로 나누어떨어지지 않으면 남는 비트를 0으로 채워 글자를 만들고, 빈 자리는 =로 적습니다. 바이트가 1개 남으면 글자 2개와 ==, 2개 남으면 글자 3개와 =가 붙습니다. RFC 4648은 인코더가 채우는 비트를 0으로 두도록 정하고, 0이 아닌 값은 디코더가 거부할 수 있다고 적습니다.

Base64 길이 계산

패딩을 붙이면 Base64 길이는 4 × ⌈n ÷ 3⌉(n = 바이트 수)이고, 패딩을 생략하면 ⌈4n ÷ 3⌉입니다. 길이를 정하는 것은 글자 수가 아니라 바이트 수입니다. 한글 음절은 UTF-8에서 한 글자가 3바이트라서, 같은 글자 수라면 영문보다 Base64가 세 배쯤 깁니다. 메일처럼 76자마다 CRLF 줄바꿈을 넣으면 줄마다 2글자가 더 붙습니다.

표준·URL-safe·MIME·PEM은 무엇이 다른가

이름은 달라도 3바이트를 4글자로 바꾸는 계산은 같습니다. 차이는 62·63번 글자, 끝의 =, 줄 나눔 세 가지뿐입니다.

디코딩 규칙도 조금씩 다릅니다. RFC 4648은 알파벳 밖 글자가 섞이면 거부하라고 정하지만, 메일용 RFC 2045는 줄바꿈과 표에 없는 글자를 무시하라고 정합니다. 브라우저의 atob()은 공백만 지우고, -나 _가 있으면 오류를 냅니다(WHATWG forgiving-base64). 이 도구는 줄바꿈·공백을 무시하고, 주소 속 %2B·%2F·%3D와 JSON 글의 \n 표기를 되돌리며, 표준과 URL-safe 글자를 모두 받습니다. 그 밖의 글자는 위치를 알려 주고 멈춥니다.

같은 글, 글자 인코딩마다 다른 Base64

Base64는 바이트를 글자로 적는 방법일 뿐이므로, 글을 어떤 바이트로 바꿨는지(글자 인코딩)에 따라 결과가 달라집니다. 영문 Hello는 UTF-8·EUC-KR·Shift_JIS에서 바이트가 같아 Base64도 같지만, 한글과 일본어는 인코딩마다 전혀 다른 값이 됩니다.

자동 판별은 먼저 첫 바이트로 PNG·JPEG 같은 파일인지 확인합니다. 그다음 ① 메일 제목·data: 주소·PowerShell처럼 인코딩이 적혀 있거나 정해진 값, ② 맨 앞의 BOM(EF BB BF, FF FE, FE FF), ③ ASCII 글자마다 00이 끼는 UTF-16 모양, ④ UTF-8의 순서로 제어 문자 없이 읽히는지 봅니다. 그래도 읽히지 않으면 EUC-KR·Shift_JIS·Windows-1252와 00이 없는 UTF-16으로 모두 읽어 보고, 그 인코딩의 글자(완성형 한글, 가나·한자, 라틴 글자)로 가장 잘 채워진 결과를 고릅니다. 점수가 같으면 페이지 언어의 인코딩(한국어 페이지는 EUC-KR)을 먼저 씁니다. 바이트만으로는 인코딩을 확정할 수 없으므로, 결과가 어색하면 조절판에서 직접 고르세요.

붙여 넣은 값의 포장, 도구가 벗기는 것

복사한 값에는 Base64 앞뒤로 헤더 이름이나 형식 표시가 붙어 있는 경우가 많습니다. 아래 모양은 포장을 벗기고 안의 Base64만 읽으며, 원문을 고치면 같은 포장으로 다시 만듭니다(서명이 필요한 JWT는 빼고). 판독 경로의 '포장 유지' 칩에서 × 단추를 누르면 포장을 뺄 수 있습니다.

풀리지 않을 때, 오류별 원인

Base64 칸의 값을 읽지 못하면 상태 줄에 몇 번째 글자에서 멈췄는지와 그 주변 글자를 보여 줍니다. 원문 칸은 흐리게 남아 마지막으로 읽은 결과를 보여 줍니다.

다른 도구와 결과가 다를 때

같은 글을 넣었는데 Base64가 다르면 거의 언제나 바이트가 다르거나 모양 설정이 다릅니다. 도구 아래쪽의 '같은 글, 다른 Base64' 목록이 지금 원문으로 아래 경우를 다시 계산해 첫 차이부터 보여 줍니다.

코드로 할 때

브라우저의 btoa()는 한 바이트에 들어가지 않는 글자가 있으면 InvalidCharacterError를 냅니다. 한글은 먼저 UTF-8 바이트로 바꾼 뒤 인코딩해야 합니다. 새 Uint8Array.prototype.toBase64()는 Chrome 140, Firefox 133, Safari 18.2부터 쓸 수 있습니다.

// JavaScript: 한글은 UTF-8 바이트로 바꾼 뒤 인코딩(짧은 글)
const bytes = new TextEncoder().encode('안녕하세요');
const b64 = btoa(String.fromCharCode(...bytes));          // 7JWI64WV7ZWY7IS47JqU
const back = new TextDecoder().decode(Uint8Array.from(atob(b64), c => c.charCodeAt(0)));
bytes.toBase64({ alphabet: 'base64url', omitPadding: true }); // 새 API

# Python
import base64
base64.b64encode('안녕하세요'.encode('utf-8'))   # b'7JWI64WV7ZWY7IS47JqU'
base64.b64decode('SGVsbG8')                      # = 없이 끝나면 binascii.Error: Incorrect padding
base64.b64decode('Zm9v-_', validate=True)        # 알파벳 밖 글자를 버리지 않고 오류

# 명령줄
printf '%s' '안녕하세요' | base64    # echo는 끝에 줄바꿈을 붙임
base64 -w 0 report.pdf              # GNU: 줄 나눔 없이(macOS base64는 기본이 한 줄, -b 76으로 나눔)

자주 틀리는 경우

• Base64를 암호화로 여기는 경우: 열쇠 없이 누구나 되돌릴 수 있습니다. 비밀번호나 토큰을 Base64로 바꿔도 가려지지 않습니다.
• echo로 만든 값을 그대로 쓰는 경우: echo는 끝에 줄바꿈을 붙여서 결과 끝이 K나 o=처럼 달라집니다. printf '%s'나 echo -n을 씁니다.
• 대소문자를 바꾸는 경우: Base64는 대문자와 소문자를 다른 글자로 읽습니다. 표기를 맞춘다고 바꾸면 다른 데이터가 되거나 풀리지 않습니다.
• 주소 쿼리에 표준 Base64를 그대로 넣는 경우: 폼 데이터 해석에서는 +가 공백으로 바뀌고, /와 =도 주소 안에서 의미가 있습니다. URL-safe를 쓰거나 퍼센트 인코딩을 합니다.
• 두 번 인코딩한 경우: 풀어 낸 결과가 다시 Base64처럼 보이면 상태 줄 옆에 '한 번 더 풀기'가 나옵니다.
• 이미지 Base64의 data: 머리를 빼먹는 경우: HTML·CSS에 넣을 때는 data:image/png;base64, 머리가 필요합니다. 이미지라면 이미지 ↔ Base64 변환기가 HTML·CSS 모양까지 만들어 줍니다.

한계

• 파일은 5MB(5,242,880바이트)까지 넣을 수 있습니다(Base64로 약 700만 자). 칸의 글이 40만 자를 넘으면 앞뒤만 보이고, 복사와 저장에는 전체가 들어갑니다.
• 자동 판별은 바이트 모양으로 추정한 결과입니다. 짧은 값은 여러 인코딩으로 읽힐 수 있어 틀릴 수 있습니다.
• 만들 수 있는 인코딩은 UTF-8, UTF-16LE·BE, EUC-KR(CP949), Shift_JIS, Windows-1252입니다. 메일 제목에 적힌 ISO-2022-JP 같은 인코딩은 읽기만 하고, 풀어 낸 글을 고치면 UTF-8로 다시 만듭니다.
• JWT의 서명은 확인하지 않고, 메일 제목의 Q 인코딩(=?…?Q?…?=)은 풀지 않습니다.
• 브라우저 글 칸은 줄바꿈을 LF로 바꾸므로 원문 칸의 줄바꿈은 LF로 인코딩됩니다. CRLF가 필요하면 '같은 글, 다른 Base64'의 CRLF 줄을 복사합니다.
• 묶음 레일은 앞 480묶음(1,440바이트)까지 그립니다. 나머지도 변환과 복사에는 들어갑니다.
• 변환은 이 브라우저 안에서만 하며, 넣은 값을 서버로 보내거나 주소·저장소에 남기지 않습니다.

출처

기준: Base64 형식은 RFC 4648, 메일·PEM·인증 헤더·JWT의 쓰임은 각 RFC, 브라우저 동작은 WHATWG 표준과 MDN, 명령줄과 언어별 동작은 각 설명서를 2026년 10월 21일에 확인했습니다. 표의 값은 이 도구와 Python 3.14 base64 모듈로 같은 결과를 확인했습니다.

• 01RFC 4648 — The Base16, Base32, and Base64 Data Encodings3.1 줄바꿈, 3.3 알파벳 밖 글자 거부, 3.5 남는 비트 0, 4절 글자표, 5절 URL-safe(- _), 10절 시험 값
• 02RFC 2045 — MIME Part One6.8 한 줄 76자 이하, 줄바꿈과 표에 없는 글자는 디코더가 무시
• 03RFC 2047 — MIME Part Three: Message Header Extensionsencoded-word 형식 =?charset?B?…?=, 한 단어 75자 이하, B = BASE64
• 04RFC 7468 — Textual Encodings of PKIX StructuresPEM 본문은 마지막 줄을 빼고 한 줄 64자
• 05RFC 7617 — The 'Basic' HTTP Authentication Scheme아이디 + ':' + 비밀번호를 Base64로, charset 값은 UTF-8만
• 06RFC 7515 — JSON Web Signature (JWS)2절 Base64url: URL-safe 글자, 끝의 = 생략, 줄바꿈 없음
• 07RFC 2397 — The "data" URL schemedata:[형식][;base64],데이터
• 08WHATWG Infra — forgiving-base64 decodeatob()의 규칙: 공백 제거, 끝 = 1~2개 허용, + / 밖 글자는 실패
• 09WHATWG — Encoding StandardTextDecoder의 UTF-8·UTF-16·EUC-KR·Shift_JIS·Windows-1252 해석
• 10MDN — Window.btoa()한 바이트에 들어가지 않는 글자는 InvalidCharacterError
• 11MDN — Uint8Array.prototype.toBase64()alphabet(base64·base64url)·omitPadding 옵션, 지원 버전은 MDN 브라우저 호환 데이터
• 12Python 3 — base64 moduleb64decode(validate=False)는 알파벳 밖 글자를 버림, urlsafe_b64encode
• 13GNU coreutils — base64(1)-w(--wrap) 기본 76자, 0이면 줄 나눔 없음
• 14Microsoft Learn — about_Pwsh-EncodedCommand 값은 UTF-16LE 문자열의 Base64
• 15Kubernetes — Secretsdata 필드 값은 Base64, 인코딩하지 않으려면 stringData

자주 묻는 질문

함께 쓰는 도구