Base64란 무엇이고 언제 쓰나요?
Base64는 임의의 바이트열을 영문 대소문자 52자, 숫자 10자, +, / 총 64개의 문자(그리고 끝을 맞추는 =)로만 표현하는 방식입니다. 텍스트만 안전하게 통과시키는 통로(이메일 본문, JSON 필드, HTTP 헤더, HTML의 data: URI, 설정 파일)에 이미지나 한글처럼 바이트가 제멋대로인 데이터를 실어 보낼 때 사용합니다. HTTP Basic 인증 헤더(Authorization: Basic ...)와 JWT의 각 구간도 이 방식(JWT는 URL-safe 변형)으로 적혀 있습니다. 이 페이지는 입력한 문자열을 UTF-8 바이트로 바꾼 뒤 Base64로 인코딩하고, 반대로 Base64를 바이트로 풀어 UTF-8 텍스트로 읽습니다.
원리: 3바이트를 4글자로
3바이트는 24비트입니다. 이를 6비트씩 4덩어리로 쪼개면 각 덩어리는 0~63 사이 값이 되고, 그 값을 64글자 표(A-Z → 0~25, a-z → 26~51, 0-9 → 52~61, + → 62, / → 63)에서 글자로 바꾼 것이 인코딩 결과입니다. 예를 들어 Man은 바이트 77·97·110이며 이진수로 이어 붙이면 010011 010110 000101 101110이 되고, 이는 19·22·5·46번 글자인 TWFu가 됩니다. 입력 길이가 3의 배수가 아니면 남는 1바이트는 글자 2개 + ==, 남는 2바이트는 글자 3개 + =로 채워 항상 4글자 단위로 끝나게 합니다. 그래서 결과 길이는 언제나 4 × ⌈바이트수 ÷ 3⌉이고, 원본보다 약 33% 커집니다.
패딩이 생기는 과정: 3바이트, 2바이트, 1바이트
입력이 3바이트 미만으로 끝나면 비트를 6의 배수가 되도록 뒤에 0을 채워 글자로 바꾸고, 부족한 자리는 =로 표시합니다. 이 패딩 =는 데이터가 아니라 "끝에서 몇 바이트가 모자랐는지"를 알려 주는 표시입니다. 아래 표는 RFC 4648의 64글자 표를 그대로 써서 계산한 결과입니다.
| 입력 | 바이트 수 | 6비트 묶음(0 채움 포함) | 글자 | 최종 결과 |
|---|---|---|---|---|
| Man | 3 | 010011 010110 000101 101110 | TWFu | TWFu |
| Ma | 2 | 010011 010110 000100 | TWE | TWE= |
| M | 1 | 010011 010000 | TQ | TQ== |
Man은 정확히 24비트라 패딩이 없고, Ma는 16비트에 0 두 개를 채워 글자 3개가 되므로 = 하나가, M은 8비트에 0 네 개를 채워 글자 2개가 되므로 ==가 붙습니다. 패딩 글자는 최대 2개이므로 ===처럼 셋 이상 이어지는 값은 정상적인 Base64가 아닙니다.
테스트 벡터 (빌드 시 계산)
아래 값은 페이지를 만들 때 UTF-8 바이트를 직접 인코딩해 채운 것이므로, 도구 결과와 대조해 구현이 맞는지 확인하는 용도로 쓸 수 있습니다.
| 입력 텍스트 | UTF-8 바이트 | Base64 결과 |
|---|---|---|
| (빈 문자열) | 0 | (빈 문자열) |
| a | 1 | YQ== |
| ab | 2 | YWI= |
| abc | 3 | YWJj |
| Hello, World! | 13 | SGVsbG8sIFdvcmxkIQ== |
| {"id":1} | 8 | eyJpZCI6MX0= |
| 안녕하세요 | 15 | 7JWI64WV7ZWY7IS47JqU |
| 😀 | 4 | 8J+YgA== |
| user:pass | 9 | dXNlcjpwYXNz |
표에서 보듯 영문 1글자는 1바이트, 한글 1글자는 3바이트(그래서 5글자가 15바이트 → 20글자), 이모지는 4바이트입니다. 같은 글자 수라도 한글 문서가 Base64로는 훨씬 길어지는 이유입니다. 빈 입력은 빈 결과가 나오며 오류가 아닙니다.
길이별 크기 변화
| 원본 바이트 | Base64 글자 수 | 패딩(=) 개수 | 원본 대비 |
|---|---|---|---|
| 1 | 4 | 2 | 400.0% |
| 2 | 4 | 1 | 200.0% |
| 3 | 4 | 0 | 133.3% |
| 10 | 16 | 2 | 160.0% |
| 100 | 136 | 2 | 136.0% |
| 1,000 | 1,336 | 2 | 133.6% |
| 1,048,576 | 1,398,104 | 2 | 133.3% |
1MB(1,048,576바이트) 파일은 약 1.33MB의 텍스트가 됩니다. 이미지를 CSS나 HTML에 직접 박으면 요청 한 번은 줄지만 파일이 커지고 캐시도 되지 않으니, 아이콘처럼 작은 것에만 쓰는 편이 낫습니다.
파일 크기별 변환 결과와 이메일 줄바꿈
파일 크기가 커져도 증가율은 약 4/3(133.3%)로 거의 일정합니다. 이메일 첨부에 쓰이는 MIME 방식은 76글자마다 줄바꿈(CRLF)을 넣는 것으로 알려져 있어, 그만큼 글자가 더 늘어납니다. 아래 표의 MIME 열은 줄 사이마다 2바이트(CR+LF)를 더해 계산한 값입니다.
| 원본 | 바이트 | Base64 글자 수 | 원본 대비 | 76자 줄 수 | MIME 줄바꿈 포함 |
|---|---|---|---|---|---|
| 아이콘 2KB | 2,048 | 2,732 | 133.4% | 36 | 2,802 |
| 작은 이미지 50KB | 51,200 | 68,268 | 133.3% | 899 | 70,064 |
| 사진 500KB | 512,000 | 682,668 | 133.3% | 8,983 | 700,632 |
| 문서 5MB | 5,242,880 | 6,990,508 | 133.3% | 91,981 | 7,174,468 |
예를 들어 JSON API로 2KB 아이콘을 문자열로 실어 보내면 2,732글자가 되어, 서버가 받는 본문 크기 제한이 있다면 원본 파일 크기보다 3분의 1쯤 큰 값을 기준으로 따져야 합니다. 이 도구는 텍스트 입력만 받으므로 위 표는 크기 감을 잡는 용도입니다.
URL-safe 변형은 언제 필요한가
표준 Base64의 +와 /는 URL에서 각각 공백, 경로 구분자로 해석될 수 있습니다. 그래서 URL·파일명·JWT에서는 + 대신 -, / 대신 _를 쓰고 끝의 =를 생략하는 변형(RFC 4648의 base64url)을 씁니다. 예: subject?>>는 표준에서 c3ViamVjdD8+Pg==, URL-safe에서 c3ViamVjdD8-Pg입니다. 체크박스를 켜고 인코딩하면 이 형태가 나오며, 디코딩할 때는 체크 여부와 관계없이 두 형식을 모두 받아들입니다.
직접 해 보기: 예시 3가지
예시 1. 입력란에 안녕하세요를 넣고 인코딩하면 7JWI64WV7ZWY7IS47JqU(20글자, 패딩 없음)가 나옵니다. 15바이트는 3의 배수라 =가 붙지 않습니다. 이 값을 입력란에 넣고 디코딩하면 다시 원문이 나옵니다.
예시 2. HTTP Basic 인증 헤더를 확인하고 싶을 때, user:pass를 인코딩하면 dXNlcjpwYXNz입니다. 헤더 값이 Basic dXNlcjpwYXNz라면 누구나 이 도구로 아이디와 비밀번호를 읽을 수 있다는 뜻이므로 HTTPS 없이 쓰면 안 됩니다.
예시 3. 디코딩할 값에 줄바꿈이나 공백이 섞여 있거나, URL-safe 문자(-, _)로 적혀 있거나, 끝의 패딩이 빠져 있어도 이 도구는 정리해서 읽습니다. 이메일(MIME)처럼 76자마다 줄바꿈된 Base64를 그대로 붙여넣어도 됩니다.
JWT 구간을 직접 읽어 보기
JWT는 점(.)으로 나뉜 세 구간 가운데 앞의 두 구간(헤더, 페이로드)이 JSON을 base64url로 인코딩한 것입니다. 예를 들어 헤더 {"alg":"HS256","typ":"JWT"}는 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9가 되고, 페이로드 {"sub":"1234567890","name":"Kim"}는 eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IktpbSJ9가 됩니다(둘 다 패딩 없음, 이름과 값은 설명용 가정입니다). 이 문자열을 입력란에 붙여 넣고 디코딩하면 JSON이 그대로 나옵니다. 다만 디코딩이 되었다는 사실이 토큰이 유효하거나 위조되지 않았다는 뜻은 아닙니다. 서명 검증은 별도 과정이며, 이 도구는 서명을 검증하지 않습니다. JWT 전체를 구간별로 해석하려면 JWT 디코더가 편합니다.
자주 하는 실수 5가지
- 두 번 인코딩.
hi를 인코딩하면aGk=인데, 이 결과를 다시 인코딩하면YUdrPQ==가 됩니다. 디코딩했는데 또 Base64처럼 보이는 문자열이 나오면 이중 인코딩을 의심하고 한 번 더 디코딩해 보세요. - Base64를 압축으로 오해. 위 표대로 결과는 항상 원본보다 커집니다. 용량을 줄이려는 목적에는 맞지 않습니다.
- 줄바꿈 차이. 텍스트에 줄바꿈이 있으면 운영체제에 따라
\n하나 또는\r\n둘로 저장되어 결과가 달라집니다.line1과line2사이가\n이면bGluZTEKbGluZTI=,\r\n이면bGluZTENCmxpbmUy입니다. 다른 환경 결과와 대조할 때 줄바꿈 종류부터 맞추세요. - URL에서 +가 사라짐. 쿼리스트링으로 받은 값에서
+가 공백으로 바뀌는 경우가 있습니다. 이 도구는 입력의 공백을 모두 제거하므로, 공백으로 변한+는 그냥 사라진 채 디코딩됩니다. 예컨대c3ViamVjdD8+Pg==에서+가 사라지면subject?>>대신subject?처럼 잘린 결과가 오류 없이 나옵니다. 결과가 이상하면 원래 문자열에+가 있었는지 먼저 확인하세요. - Base64와 16진수(hex)를 혼동. 같은
hi가 Base64로는aGk=, 16진수로는6869입니다. 둘 다 바이트를 글자로 적는 방식이지만 길이와 쓰는 글자가 다릅니다. 16진수 표현은 텍스트-이진수/ASCII 변환기에서 볼 수 있습니다.
엣지 케이스와 한계
한글·이모지. 이 도구는 문자열을 먼저 UTF-8 바이트로 바꾼 뒤 인코딩합니다. 다른 도구나 언어에서 같은 한글이 다른 결과를 내면 대개 UTF-8이 아닌 인코딩(예: EUC-KR/CP949, UTF-16)으로 바이트를 만든 것입니다. 이 도구의 디코딩은 UTF-8 해석만 지원하므로 EUC-KR 바이트가 들어 있으면 "UTF-8 텍스트가 아님" 안내가 나옵니다.
바이너리 데이터. 이미지, PDF, 암호화된 바이트를 디코딩하면 UTF-8로 읽을 수 없어 오류 안내가 나옵니다. 이 도구는 텍스트 전용이며 파일 변환용이 아닙니다.
잘못된 입력. Base64에 쓸 수 없는 글자(예: !, 한글)가 섞였거나, 패딩을 뺀 글자 수를 4로 나눈 나머지가 1이면(남는 글자 하나로는 바이트를 만들 수 없음) 디코딩할 수 없다고 알려 줍니다.
큰 입력. 수백 KB 수준의 텍스트까지는 즉시 처리되는 것이 일반적이지만, 매우 큰 입력은 브라우저 탭이 잠시 멈출 수 있습니다. 변환은 청크 단위로 진행해 글자 수 제한 오류는 나지 않게 했습니다.
보안·개인정보
이 페이지의 변환 스크립트는 입력값을 읽어 브라우저 안에서 변환만 하며, 입력을 서버로 보내는 네트워크 요청(fetch, XMLHttpRequest 등)을 하지 않습니다. 입력 내용을 저장하지도 않습니다. 다만 광고 스크립트 등 사이트의 다른 구성요소는 별도로 동작할 수 있으므로, 운영 중인 비밀번호나 API 키처럼 민감한 값은 가급적 로컬 환경에서 처리하기를 권합니다. 무엇보다 Base64는 암호화가 아닙니다. 키 없이 누구나 되돌릴 수 있기 때문에 "Base64로 바꿨으니 안전하다"는 판단은 위험합니다. 비밀 보호가 목적이면 암호화나 해시를 써야 합니다.
결과를 어디에 쓰나
인증 헤더 값 확인, JWT 각 구간 확인(구간만 URL-safe로 디코딩하면 JSON이 보입니다), 설정 파일에 들어 있는 인코딩 값 점검, 테스트 데이터 생성에 활용합니다. 디코딩 결과가 JSON이면 JSON 포맷터로 들여쓰기를 맞추면 읽기 쉽습니다.
자주 묻는 질문
Base64는 암호화인가요?
아니요. Base64는 인코딩이지 암호화가 아닙니다. 누구나 쉽게 디코딩할 수 있으므로 비밀번호나 민감 정보를 보호하는 용도로는 사용하면 안 됩니다.
한글이 깨져서 나와요.
이 도구는 UTF-8을 기준으로 하므로 한글도 정상적으로 인코딩/디코딩됩니다. 다른 곳에서 만든 Base64를 디코딩할 때 깨지거나 오류가 난다면 원본이 EUC-KR 같은 다른 인코딩이거나 텍스트가 아닌 바이너리일 가능성이 큽니다.
끝에 붙는 =는 왜 있고, 빼도 되나요?
입력 길이가 3의 배수가 아닐 때 4글자 단위를 맞추는 패딩입니다. URL-safe 형식에서는 생략하는 경우가 많고, 이 도구의 디코딩은 패딩이 없어도 길이를 계산해 처리합니다. 다만 엄격한 라이브러리 중에는 패딩이 없으면 거부하는 것도 있습니다.
+와 /가 들어 있는 값이 URL에서 깨져요.
표준 Base64의 +는 쿼리스트링에서 공백으로 읽힐 수 있고 /는 경로로 오해됩니다. URL-safe 옵션으로 인코딩하거나 값을 URL 인코더로 한 번 더 퍼센트 인코딩하세요.
해시와는 뭐가 다른가요?
Base64는 같은 입력이 항상 같은 결과를 내고 언제든 되돌릴 수 있으며, 길이가 입력에 비례합니다. 해시는 되돌릴 수 없는 고정 길이 지문입니다. 해시값이 필요하면 해시 생성기를 쓰세요.
입력한 내용이 서버로 전송되나요?
이 페이지의 변환 코드는 네트워크 요청을 하지 않고 브라우저 안에서만 실행됩니다. 그래도 민감한 값은 신뢰할 수 있는 환경에서만 다루세요.
인코딩한 결과 길이로 원본 크기를 알 수 있나요?
대략 알 수 있습니다. 결과 글자 수가 L이고 끝에 =가 p개 있다면 원본 바이트 수는 L × 3 ÷ 4 − p입니다. 예를 들어 TWE=는 4 × 3 ÷ 4 − 1 = 2바이트(Ma)입니다. 줄바꿈이 섞였다면 먼저 제거하고 세어야 합니다.
같은 텍스트인데 다른 사이트의 결과와 달라요.
흔한 원인은 세 가지입니다. 문자 인코딩이 UTF-8이 아닌 경우(EUC-KR, UTF-16), 줄바꿈이 \n과 \r\n으로 다른 경우, URL-safe와 표준 형식을 섞은 경우입니다. 먼저 바이트 수를 비교하면 원인을 좁히기 쉽습니다. 이 도구는 인코딩할 때마다 UTF-8 바이트 수를 함께 보여 줍니다.
이미지 파일을 Base64로 바꿔 주나요?
이 도구는 텍스트 입력 전용입니다. 이미지·PDF 같은 바이너리를 변환하는 기능은 없으며, 바이너리 Base64를 디코딩하면 UTF-8로 읽을 수 없다는 안내가 나옵니다. 파일 단위 변환이 필요하면 해당 작업을 지원하는 프로그램이나 라이브러리를 사용하세요.
비밀번호를 Base64로 저장해도 되나요?
안 됩니다. Base64는 키 없이 누구나 되돌릴 수 있는 인코딩이라 보호 효과가 없습니다. 비밀번호는 목적에 맞는 비밀번호 해시 방식으로 저장하는 것이 일반적인 권고입니다. 값을 되돌릴 수 없다는 점에서 해시와 Base64는 용도가 완전히 다릅니다.
관련 도구
- URL 인코더/디코더 - 퍼센트 인코딩 변환
- JWT 디코더 - 토큰의 Base64URL 구간 해석
- 텍스트-이진수/ASCII 변환기 - 바이트 표현 확인
- 해시 생성기 - 되돌릴 수 없는 지문 만들기