Base64 인코딩 및 디코딩
텍스트나 파일을 Base64로 인코딩하고 문자열을 바이트로 디코딩. 브라우저에서 실행. 패딩 예, RFC 4648 알파벳, URL-safe 변형 포함.
모든 계산은 브라우저에서 실행됩니다. 입력한 내용은 서버로 전송되지 않습니다.
입력하면 결과가 갱신됩니다. Ctrl/Cmd+Enter로 주요 결과 복사.
결과
—
비트 보기
풀이 보기
Base64 인코딩·디코딩은 임의의 바이트를 RFC 4648 알파벳으로 ASCII 문자열에 변환하고, 그 문자열을 원래 바이트로 되돌립니다. 텍스트 모드는 UTF-8 같은 문자 인코딩을 받습니다. 파일 모드는 브라우저 FileReader로 업로드를 읽고 삽입용 data: URI를 낼 수 있습니다. 인코딩은 암호화가 아닙니다. 문자열을 받은 사람은 누구나 디코딩할 수 있습니다.
인코딩과 디코딩은 모두 브라우저에서 실행됩니다. 붙여 넣은 내용이 서버로 전송되지 않습니다.
텍스트 또는 파일을 Base64로 인코딩하기
인코딩은 원시 바이트를 A부터 Z, a부터 z, 0부터 9, 플러스, 슬래시, 패딩 = 문자열로 씁니다. 텍스트를 붙이거나 파일을 고르고, 소스가 텍스트일 때 문자 인코딩을 선택한 뒤 출력을 읽습니다.
파일 모드는 JSON, XML, 이메일처럼 이진 채널 없이 이동해야 하는 작은 이미지와 문서에 적합합니다.
출력은 오래된 메일 게이트웨이나 XML에 복사·붙여넣기처럼 임의의 이진을 손상시키는 시스템을 통과해도 안전합니다. 의도적으로 입력보다 깁니다. 잘못된 빈 입력은 문자열을 내지 않습니다. 도구는 바이트를 받을 때까지 문자를 출력하지 않습니다.
Base64 문자열을 데이터로 디코딩하기
디코딩은 알파벳 조회를 뒤집고 원래 비트 스트림을 재구성해 텍스트나 다운로드 가능한 파일을 반환합니다. 끝의 패딩 = 문자는 중요합니다. 마지막 불완전 그룹에 몇 바이트가 있었는지 표시합니다. 알파벳 밖 문자는 조용히 부분 디코딩하지 않고 명확한 오류를 냅니다.
공백은 흔히 무시되어 PEM 인증서나 MIME 본문에서 복사한 문자열도 동작합니다. Base64처럼 보이지만 URL-safe 알파벳을 쓰는 문자열은 URL-safe 디코드 모드가 필요합니다. 그렇지 않으면 하이픈과 밑줄이 표준 알파벳에서 불법으로 거부됩니다.
Base64 인코딩 동작 이해하기
Base64는 입력을 3바이트(24비트) 블록으로 처리합니다. 24비트를 6비트씩 네 그룹으로 나눕니다. 각 6비트 값은 64문자 알파벳의 0~63 인덱스입니다. 따라서 입력 3바이트는 출력 4문자가 됩니다.
Bytes: [ byte1 ][ byte2 ][ byte3 ]
Bits: aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars: Char1 Char2 Char3 Char4
3바이트 미만이 남으면 인코더는 여전히 네 문자를 내지만, 디코더가 원래 길이를 알 수 있게 패딩을 추가합니다. 비트 재그룹화가 알고리즘 전체입니다. 체크섬도 키도 없습니다.
Dog 단어를 단계별로 인코딩하기
단어 Dog는 3바이트 ASCII이므로 Base64 그룹 하나를 채우고 패딩 문자 없이 인코딩됩니다. 고정 출력은 RG9n입니다. 바이트를 비트로, 6비트 인덱스로 재그룹화하고 RFC 4648 알파벳을 보면 왜 이 네 문자가 나오는지, 임의의 3바이트 블록이 같은 경로를 따르는지 알 수 있습니다.
1. 바이트를 쓴다. D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111
2. 24비트를 이어 붙인다. 01000100 01101111 01100111
3. 6비트 그룹으로 나눈다. 010001 000110 111101 100111
4. 각 그룹을 10진 인덱스로 바꾼다. 17, 6, 61, 39
5. 알파벳을 조회한다. 인덱스 17 = R, 6 = G, 61 = 9, 39 = n
결과: RG9n. RG9n을 디코딩하면 세 원본 바이트와 UTF-8 또는 ASCII에서 텍스트 Dog가 돌아옵니다.
등호 패딩 이해하기
바이트 수가 3의 배수가 아니면 패딩이 생깁니다. 남은 1바이트는 알파벳 문자 두 개와 = 두 개를 만듭니다. 남은 2바이트는 문자 세 개와 = 하나를 만듭니다. 고정 예 Do → RG8=와 Dogs → RG9ncw==는 패딩 없는 3바이트 단어 Dog 옆에 두 나머지 경우를 보여 줍니다.
| Input | Bytes | Encoded | Padding |
|---|---|---|---|
| Dog | 3 | RG9n | none |
| Do | 2 | RG8= | one = |
| Dogs | 4 | RG9ncw== | two = |
Do는 2바이트: 01000100 01101111. 6비트 그룹화 후 의미 있는 문자는 세 개(RG8)분의 비트만 있고, 패딩 = 하나가 네 번째 자리를 채웁니다. Dogs는 4바이트: 완전한 3바이트 그룹이 RG9n으로 인코딩되고, 1바이트 나머지가 cw==로 인코딩됩니다. 비트 길이를 조정하지 않고 패딩을 손으로 제거하면 디코딩이 깨집니다. 붙여 넣을 때 = 문자를 그대로 두세요.
Base64 알파벳 읽기
RFC 4648은 64문자와 패딩 기호 =를 정의합니다. 인덱스 0~25는 A~Z, 26~51은 a~z, 52~61은 0~9, 인덱스 62는 +, 인덱스 63은 /입니다.
인덱스 0은 0이 아니라 A입니다. 숫자가 알파벳 앞에 온다고 기대하는 사람을 헷갈리게 합니다.
| Index range | Characters |
|---|---|
| 0 to 25 | A to Z |
| 26 to 51 | a to z |
| 52 to 61 | 0 to 9 |
| 62 | + |
| 63 | / |
| padding | = |
계산기 알파벳 패널은 인코더가 쓰는 것과 같은 표를 나열하므로 의심스러운 문자를 표준 집합과 대조할 수 있습니다. 전체 문자열은 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/입니다.
URL-safe Base64 변형 사용하기
URL-safe 알파벳(base64url)은 +를 -로, /를 _로 바꿉니다. 일부 프로토콜에서는 패딩을 생략할 수 있습니다. JSON Web Token은 이 변형을 써서 토큰 세그먼트를 URL과 HTTP 헤더에 두어도 플러스와 슬래시를 퍼센트 인코딩할 필요가 없습니다.
표준과 URL-safe 문자열은 호환되지 않습니다. 표준 알파벳으로 JWT 페이로드를 디코딩하면 하이픈에서 실패합니다. 도구는 인코드와 디코드 모두에 명시적 URL-safe 모드를 제공합니다. URL 퍼센트 인코딩은 다른 문제입니다. Base64가 아니라 RFC 3986 이스케이프가 목적이면 URL 인코딩 및 디코딩 페이지를 사용하세요.
크기 증가 고려하기
3바이트마다 4문자가 되므로 인코딩 길이는 입력의 약 4/3, 줄바꿈 전 33퍼센트 증가입니다. 패딩은 마지막 그룹에 한두 문자를 더할 수 있습니다. data URI와 이메일 첨부는 이 비용을 빨리 느낍니다: 300 KB 이미지는 대략 400 KB 텍스트가 됩니다.
encoded_length ≈ 4 × ceil(byte_length / 3)
76자 줄바꿈(MIME에서 흔함)은 그 위에 개행 바이트를 더합니다. 크기가 중요하면 이진 첨부나 압축 형식을 우선하고, 채널이 정말 원시 바이트를 못 실을 때만 Base64를 쓰세요.
문자 인코딩 선택하기
Base64는 추상 문자가 아니라 바이트를 인코딩합니다. 같은 글자도 UTF-8, UTF-16, Shift JIS, Big5에서 다른 바이트가 됩니다. Base64 층이 완벽해도 디코드 후 해석 charset이 맞지 않으면 깨진 글자가 됩니다. 텍스트 모드 charset은 인코드 시 생산자, 디코드 시 소비자와 맞춰야 합니다.
| Charset | Typical use |
|---|---|
| UTF-8 | Default for modern text and APIs |
| Windows-1252 | Legacy Western European text |
| UTF-16 LE / BE | Some Windows and Java payloads |
| Shift JIS | Older Japanese text |
| Big5 | Older Traditional Chinese text |
단어 Dog에서는 ASCII와 UTF-8이 같은 3바이트이므로 RG9n이 같습니다. 비 ASCII 텍스트는 갈라집니다. 인코드 전 생산자에 맞는 charset을, 디코드 후에도 같은 charset을 고르지 않으면 상류 실수인데 Base64 버그처럼 보입니다.
자주 묻는 질문
Base64는 암호화인가요?
아니요. Base64는 공개 알파벳으로 누구나 되돌릴 수 있는 인코딩입니다. 아무것도 숨기지 않습니다. 기밀성이 필요하면 진짜 암호 알고리즘을 쓰고, 채널이 ASCII 안전 바이트가 필요할 때 Base64를 쓰세요.
Base64 출력 끝에 등호가 붙는 이유는?
= 문자는 패딩입니다. 마지막 입력 그룹이 3바이트가 아니라 1 또는 2바이트였음을 표시합니다. Do는 RG8=로, Dogs는 RG9ncw==로 인코딩됩니다. 프로토콜이 제거했다고 문서화하지 않는 한 디코드할 때 패딩을 유지하세요.
Dog는 무엇으로 인코딩되나요?
Dog는 3바이트로 Base64 그룹 하나를 정확히 채우므로 패딩 없이 RG9n입니다. 단계별 비트 재그룹화는 이 페이지의 계산 예에 나와 있습니다.
표준 Base64와 URL-safe Base64의 차이는?
URL-safe Base64는 +와 / 대신 -와 _를 씁니다. JWT와 일부 파일명 삽입이 URL-safe 알파벳을 씁니다. 잘못된 알파벳으로 디코드하면 치환 문자에서 실패합니다.
Base64는 원본보다 얼마나 큰가요?
약 3분의 1 더 큽니다. 3바이트가 4문자이므로 패딩과 줄바꿈 전 비율은 4/3입니다. 3,000바이트 페이로드는 4,000자 Base64가 됩니다.
텍스트뿐 아니라 파일도 Base64로 인코딩할 수 있나요?
예. 파일 모드는 브라우저에서 업로드를 읽고 원시 바이트를 인코딩합니다. 역방향은 blob으로 다운로드 가능하게 디코드합니다. 큰 파일은 탭 메모리 사용을 늘리므로 업로드는 적당히 하세요.
올바르게 디코드했는데 텍스트가 이상해 보이는 이유는?
Base64 층은 바이트를 복원했지만, 그 바이트를 해석하는 문자 인코딩이 생산자와 맞지 않습니다. 먼저 UTF-8을 시도하고, 소스 시스템이 실제로 쓰는 charset을 시도하세요.
이 도구는 붙여 넣은 비밀을 업로드하나요?
아니요. 인코딩과 디코딩은 로컬에서 실행됩니다. API 키, 토큰, 인증서 조각을 상자에 붙여도 서버로 가지 않습니다. 이 약속은 Quick Calculators의 모든 인코딩 페이지 설계 원칙과 같습니다.
Base64는 URL 인코딩과 같나요?
아니요. Base64는 이진을 운송용 64문자 알파벳에 매핑합니다. URL 인코딩(퍼센트 인코딩)은 RFC 3986에 따라 URI 안 예약 문자를 이스케이프합니다. 다른 문제를 풀며 서로 대체가 아닙니다.
알파벳을 정의하는 RFC는?
RFC 4648이 여기서 쓰는 표준 및 URL-safe Base64 알파벳과 패딩 규칙을 정의합니다. RFC 2045 같은 오래된 문서는 MIME 맥락의 Base64를 비슷한 방식으로 설명합니다.
요약
Base64 인코딩·디코딩은 6비트 그룹으로 바이트를 RFC 4648 알파벳에 매핑하고 브라우저에서 로컬로 되돌립니다. Dog는 RG9n, Do는 RG8=, Dogs는 RG9ncw==가 되어 1바이트와 2바이트 나머지 패딩을 보여 줍니다.
URL-safe 알파벳은 +//를 -/_로 바꾸고, 출력은 약 3분의 1 늘며, charset 선택이 텍스트 모드가 인코더에 넣는 바이트를 정합니다. 붙여 넣은 내용은 업로드되지 않습니다.