Base64 인코딩/디코딩 도구
빠르게 Base64 인코딩 및 디코딩을 수행하며, UTF-8 텍스트 변환을 지원합니다
변환 방식 선택
Base64란?
Base64는 64개의 출력 가능한 문자를 사용하여 이진 데이터를 표현하는 방법입니다. 이 64개의 문자에는 대문자 A-Z, 소문자 a-z, 숫자 0-9, 그리고 +와 / 두 개의 기호가 포함됩니다. 출력 가능한 문자만 사용하기 때문에, Base64로 인코딩된 데이터는 이메일, 웹페이지, JSON 등 텍스트만 지원하는 환경에서 안전하게 전송할 수 있습니다. 인코딩된 데이터는 원본 데이터보다 약 33% 증가합니다. Base64는 1987년 PEM 프로토콜에서 처음 등장하여, 이메일에서 이진 데이터를 안전하게 전송하는 데 사용되었습니다. 현재는 인터넷 표준 중 하나가 되어, 이메일 첨부 파일부터 JWT 토큰, 이미지 임베딩부터 데이터 전송까지 다양한 상황에서 광범위하게 사용됩니다. 거의 모든 프로그래밍 언어에 Base64 인코딩/디코딩 기능이 내장되어 있습니다.
사용 방법
사용 방법
- 왼쪽 입력 상자에 텍스트를 붙여넣으세요
- '인코딩' 또는 '디코딩' 작업을 선택하세요
- 결과가 오른쪽에 자동으로 표시됩니다
- 복사 버튼을 클릭하여 결과를 저장하세요
흔한 실수
- Base64는 인코딩이지 암호화가 아닙니다. 텍스트를 가진 누구나 디코딩할 수 있으므로 비밀 보호에 사용하지 마세요.
- 디코딩에 실패하면 누락된 패딩, 복사된 줄 바꿈, URL-safe Base64 문자 또는 주변 따옴표를 확인하세요.
활용 사례
기술 원리
Base64는 RFC 4648(S. Josefsson, 2006년 10월)에 명시된 여러 이진-텍스트 인코딩 중 하나로, Base16(16진수) 및 Base32와 함께 정의됩니다. 'Base64'라는 이름과 알파벳은 원래 Privacy-Enhanced Mail(RFC 989, 1987)에서 정의되었으며, PEM은 7비트 전송 환경에서 안전하게 전달할 수 있도록 바이너리 S/MIME 및 X.509 자료를 인쇄 가능한 ASCII 봉투로 감싸는 데 사용되었습니다. 동일한 알파벳은 이후 MIME(RFC 2045), JWT 서명(RFC 7519), HTML data: URI(RFC 2397), SSH 공개 키 블롭(RFC 4253 §6.6), Git LFS 포인터 파일(SHA-256 해시를 Base64로 저장)의 사실상 표준이 되었습니다. Git 자체의 팩파일은 Base64가 아닙니다 — zlib 압축과 델타 인코딩을 사용하며, Git 객체 ID는 Base64가 아닌 40자리 16진 SHA-1 문자열입니다. 비용: 입력 3바이트마다 출력 4문자가 되므로 인코딩된 출력은 정확히 4/3 크기(33.3% 오버헤드)입니다. 10MB 바이너리 블롭의 경우 인코딩된 형태는 약 13.3MB입니다. 메커니즘: 입력을 3바이트(24비트) 그룹으로 분할합니다. 각 그룹은 네 개의 6비트 값으로 분해되고, 각 6비트 값은 64문자 알파벳에서 하나의 문자를 선택합니다. 표준 알파벳은 A-Z(인덱스 0-25), a-z(26-51), 0-9(52-61), '+'(62), '/'(63)이며, '='를 패딩 문자로 사용합니다. 대표적인 RFC 4648 예시: 'Man'(0x4d 0x61 0x6e)은 24비트 값 0x4d616e으로 패킹되고, 6비트 청크로 분할하면 0x0d 0x16 0x0e 0x0a가 되어 'TWFu'에 매핑됩니다. 입력 길이가 3의 배수가 아닌 경우, 끝 그룹은 오른쪽에 0으로 패딩됩니다: 1바이트 남음 → 2개의 유효한 6비트 청크 + '=='(패딩 2개). 2바이트 남음 → 3개의 유효 청크 + '='(패딩 1개). 패딩 문자는 정보를 담지 않지만, 인코딩 길이를 입력 길이의 결정적 함수로 만들고 디코더가 잘린 입력을 거부할 수 있게 합니다. 브라우저에서 Base64에는 두 가지 악명 높은 함정이 있습니다. 첫째, `btoa`와 `atob`(DOMString 변형)는 Latin-1 코드 단위에서 작동하며 바이트가 아닙니다 — U+00E9(é)나 U+4E2D(중)를 포함하는 문자열을 전달하면 InvalidCharacterError가 발생합니다. 이 페이지는 `btoa` 호출 전에 `TextEncoder().encode(str)`(항상 UTF-8)을 통과시키고, `atob` 후에 `TextDecoder().decode(bytes)`를 사용하여 이 문제를 해결합니다. UTF-8 다중 바이트 문자는 확장됩니다: '당신'은 3바이트(0xe4 0xbd 0xa0) → 4개의 base64 문자('안녕하세요'는 8개의 base64 문자). 둘째, Base64URL(RFC 4648 §5)은 '+'와 '/'를 '-'와 '_'로 대체하고 패딩을 제거합니다. '+'와 '/'는 URL에서 의미 있는 문자이고 '='는 쿼리 문자열을 종료하기 때문입니다. JWT(RFC 7519)와 JWS(RFC 7515)는 바로 이 이유로 Base64URL을 요구합니다. Base64는 인코딩이지 암호화가 아닙니다 — 인코딩된 형태는 비밀성이 전혀 없으며, 알파벳이 너무 짧아서 관찰자가 결과를 쉽게 읽을 수 있습니다. Base64를 보안 메커니즘으로 착각하는 것은 CVE 패턴입니다: CVE-2004-2761은 공격자가 충돌하는 MD5 서명으로 인증서를 위조할 수 있게 한 X.509 MD5 선택 접두어 충돌을 기록했으며, CVE-2005-4900 등은 `$1$` md5crypt 비밀번호 해시를 인증 계층이 Base64 디코딩된 바이트를 새로운 자격 증명과 혼동하여 재인코딩하거나 재해시하던 관행과 관련이 있습니다. 반복되는 패턴은 동일합니다: 시스템이 실제로 제공하지 않는 비밀성 계층을 추가한다고 인코딩을 취급하고, 그 결과 악용 가능해집니다. 진정한 비밀에는 AES-GCM(RFC 5288) 또는 ChaCha20-Poly1305(RFC 8439)를 사용하세요. 압축 후 Base64(`gzip -b64`가 수행)의 경우, 인코딩된 형태는 gzip된 크기의 약 1.37배이며, 압축 스트림의 바이트 변경은 디코딩을 깨뜨립니다 — 따라서 Base64는 무결성 계층으로 부적절하며, 인코딩 전 바이트에 대한 HMAC-SHA256이 올바른 접근법입니다.
- RFC 4648(2006년 10월)은 하나의 표준 알파벳(A-Z, a-z, 0-9, +, /)과 '=' 패딩 문자로 Base64, Base32, Base16을 정의합니다. MIME 변형(RFC 2045)은 전송을 위해 76자마다 줄 바꿈을 삽입하고, URL 안전 변형(Base64URL, RFC 4648 §5)은 +와 /를 -와 _로 대체하고 패딩을 제거합니다 — JWT(RFC 7519), JWS(RFC 7515), JWK(RFC 7517)에서 사용됩니다.
- 메커니즘: 입력 3바이트(24비트) → 출력 4문자(각 6비트). 오버헤드는 33.3% — 1MB 바이너리 입력은 1.33MB Base64가 됩니다. ASCII의 경우 입력에 '=' 또는 주변 프로토콜에 의해 이스케이프되는 다른 문자가 포함되면 비율이 더 나빠질 수 있습니다.
- 패딩 규칙: 입력 길이 mod 3 = 0 → 패딩 없음; mod 3 = 1 → '=='(패딩 2개, 1바이트 인코딩됨); mod 3 = 2 → '='(패딩 1개, 2바이트 인코딩됨). '='는 정보를 담지 않으며, 디코더에게 몇 바이트가 삭제되었는지 알려주는 역할만 합니다.
- UTF-8 + btoa 함정: `btoa('é')`는 btoa가 입력을 Latin-1 코드 단위로 처리하기 때문에 InvalidCharacterError를 발생시킵니다. 이 페이지는 btoa 전에 `TextEncoder`(UTF-8)를 통해 인코딩하고, atob 후에 `TextDecoder`를 통해 디코딩하여 이 문제를 해결합니다. 이 단계 없이 U+0000..U+00FF 범위 밖의 모든 것은 오류 대신 '0바이트 인코딩됨'이 됩니다.
- Base64URL은 JWT, JWS, JWK(RFC 7519/7515/7517)에 필수입니다. '+'와 '/'(URL에서 의미 있는 문자) 대신 '-'와 '_'를 사용하고 '=' 패딩(쿼리 문자열을 종료함)을 제거합니다. JWT 헤더 세그먼트를 Base64URL 디코더 대신 Base64 디코더에 전달하면 쓰레기가 반환됩니다. 이 페이지는 자동 감지를 하지 않으므로 페이로드에 맞는 변형을 선택하세요.
- 성능: 최신 노트북의 V8에서 인코딩은 약 400-700MB/s입니다(테이블 조회와 비트 시프트를 수행하는 타이트한 루프). 디코딩도 비슷한 속도입니다. 대용량 블롭(10MB 이상)에서는 병목이 연산이 아닌 할당에 있습니다 — 출력 버퍼가 33% 크고 `TextEncoder/TextDecoder`가 복사본을 만듭니다.
- Base64는 인코딩이지 암호화가 아닙니다 — 문자열을 가진 누구나 읽을 수 있습니다. CVE-2004-2761(X.509 MD5 선택 접두어 충돌, 인증서 서명)과 많은 MISC-CTF 해설이 이 오해를 첫 번째 디딤돌로 사용합니다. 비밀에는 AES-GCM(RFC 5288) 또는 ChaCha20-Poly1305(RFC 8439)를 사용하세요. data: URI의 경우 인코딩된 크기를 주의하세요: 10MB 이미지는 13.3MB URL이 되어 대부분의 브라우저 URL 길이 제한과 이메일 크기 제한을 초과합니다.
- 마이그레이션 참고: Base16(16진수)은 각 바이트가 정확히 2문자에 매핑되고 길이가 예측 가능(패딩 수학 불필요)하여 저수준 프로토콜과 해시 출력에서 선호됩니다. Base32는 사람이 전사하기에 유사한 문자가 없어 선호됩니다. Base64는 텍스트 프로토콜에서 바이너리 전송의 보편적 기본값이지만, 프레이밍이 허용되는 HTTP/2와 WebTransport에서 원시 바이트로 점차 대체되고 있습니다.
예시
ASCII 텍스트 인코딩
입력: Hello
출력: SGVsbG8= (5바이트 -> 8자, 패딩 1자)
입력: Hello, World!
출력: SGVsbG8sIFdvcmxkIQ== (13바이트 -> 18자, 패딩 1자)
입력: Man
출력: TWFu (3바이트 -> 4자, 패딩 없음)
'Man' 예시는 RFC 4648의 표준 벡터입니다. 바이트 0x4D 0x61 0x6E이
24비트 값 0x4D616E으로 묶인 뒤 6비트 단위 0x0D 0x16 0x0E 0x0A로
분할되며, 표준 알파벳에 따라 T W F u로 매핑됩니다.UTF-8 텍스트 인코딩 (중국어)
입력: ni hao (ASCII 3바이트)
출력: 5L2g5aW9 (8자)
입력: ni hao shi jie (CJK 4문자, UTF-8 12바이트)
출력: 5L2g5aW95LiW55WM (16자)
CJK 문자 하나당 UTF-8 3바이트(E4 BD A0 등)로 확장되므로,
Base64 출력은 4/3배가 되고 다시 4/3배가 되어 원래 문자 수의
약 2.67배 크기가 됩니다. 페이지는 비-ASCII 입력에서 발생하는
btoa('InvalidCharacterError')를 피하려고 먼저
TextEncoder().encode(str)로 처리합니다.JWT 세그먼트 디코딩 및 라운드트립
인코딩됨: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
디코딩됨: {"alg":"HS256","typ":"JWT"}
라운드트립:
encode('{"alg":"HS256","typ":"JWT"}') -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
decode('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') -> {"alg":"HS256","typ":"JWT"}
JWT 세그먼트는 Base64URL을 사용하므로, 페이지는 표준 '+' / '/'
외에 '-' / '_'도 받아들여야 합니다. JWT 헤더를 엄격한 Base64
디코더에 넣으면 의미 없는 결과가 나오므로, 페이로드에 맞는
변형을 선택해야 합니다.Base64 vs Base64URL
입력: Hello><h2>
표준: SGVsbG8+PGgyPg== (+ / = 패딩; JSON / 이메일 안에서 안전)
URL-safe: SGVsbG8-PGIyPg (- _ 패딩 없음; URL 경로/쿼리 안에서 안전)
차이점:
'+' (62) -> '-' 그리고 '/' (63) -> '_'
URL-safe 형식에서는 '=' 패딩이 모두 제거됨
JWT, JWS, JWK 및 URL 쿼리 문자열로 전달되는 토큰에는 Base64URL을
사용하세요. '+' / '/'는 URL에서 의미가 있는 문자이고 '='는 쿼리를
종료시키기 때문입니다.자주 묻는 질문
Base64는 암호화인가요?
아닙니다. Base64는 인코딩이지 암호화가 아닙니다. 임의의 바이트를 64개의 출력 가능한 ASCII 문자(A-Z, a-z, 0-9, +, /)로 변환하여 바이너리 데이터를 망가뜨릴 수 있는 시스템을 통과하도록 만드는 것일 뿐입니다. 인코딩된 문자열만 있으면 누구나 즉시 원래 값으로 복원할 수 있으며, 비밀 키 같은 요소는 전혀 없습니다.
인코딩 결과 끝에 = 또는 == 가 붙는 이유는 무엇인가요?
Base64는 입력 3바이트마다 출력 4문자를 만듭니다. 입력 길이가 3의 배수가 아니면 결과 길이가 4의 배수가 되도록 인코더가 = 로 패딩합니다. 입력에 1바이트가 남으면 == 두 개, 2바이트가 남으면 = 한 개, 정확히 맞으면 패딩이 없습니다. 일부 구현은 패딩을 생략하기도 하는데, 이는 규격상 허용되지만 모든 곳에서 호환되지는 않습니다.
URL 안전 Base64란 무엇인가요?
표준 Base64는 URL과 파일명에서 특별한 의미를 갖는 / 와 + 를 포함합니다. URL 안전 Base64(RFC 4648 §5)는 이를 _ 와 - 로 바꾸고 종종 = 패딩을 생략합니다. JWT 토큰, URL 매개변수, 파일명에는 URL 안전 Base64를, 그 외 일반적인 경우에는 표준 Base64를 사용하세요.
Base64 문자열이 원본보다 약 33% 더 긴 이유는 무엇인가요?
입력 6비트마다 8비트 출력 문자 하나로 변환되므로, 인코딩된 크기는 ceil(input_length / 3) * 4 입니다. 이는 대략 입력의 4/3(33% 오버헤드)에 해당합니다. 임의의 바이트를 출력 가능한 ASCII로 표현하기 위해 치르는 비용입니다.
어떤 입력 형식을 붙여넣을 수 있나요?
인코딩 시에는 평문(내부적으로 UTF-8로 인코딩됨)을 붙여넣거나 파일을 업로드하면 됩니다. 디코딩 시에는 공백이 있어도 없어도 되는 Base64 문자열을 붙여넣으세요. 디코더가 줄바꿈을 자동으로 제거합니다. 디코딩이 실패한다면 잘못된 문자가 섞여 있거나 = 패딩이 누락되었을 가능성이 높습니다.
Base64로 바이너리 파일 내용을 담을 수 있나요?
네. 그것이 주된 용도입니다. HTML/CSS의 인라인 이미지(data: URL), 이메일 첨부(MIME), HTTP 헤더의 자격 증명(Basic Auth) 모두 Base64를 통해 텍스트 전용 채널에 바이너리를 실어 나릅니다. 결과 페이로드는 원본 파일보다 33% 커진다는 점을 유의하세요.
민감한 데이터를 숨기려고 Base64를 써도 될까요?
절대 안 됩니다. Base64는 키 없이도 완전히 되돌릴 수 있습니다. 이를 난독화로 착각해 사용하는 것은 흔한 실수이며, 실제로 많은 사고에서 비밀번호와 토큰이 이런 식으로 유출되었습니다. 민감한 데이터에는 반드시 적절한 암호화나 시크릿 관리 도구를 사용하세요.