Base64 인코더 / 디코더 (UTF-8 및 URL-safe)

텍스트나 Base64 문자열을 입력하면 양방향 변환. UTF-8(이모지와 CJK 포함) 처리 및 JWT와 OAuth에서 사용되는 URL-safe 변형 지원.

URL-safe (-, _, 패딩 없음)

일반 텍스트

인코딩 결과

작동 방식

Base64가 무엇이고 무엇이 아닌지

Base64는 64자 알파벳(A-Z, a-z, 0-9, +, / 및 = 패딩) 사용해 임의 바이트 인코딩. JSON, HTML, 이메일 헤더 같은 텍스트 전용 형식에 이진 데이터 — 이미지 바이트, 암호화된 블롭, 서명된 토큰 — 임베딩하는 표준 방식. 출력은 입력보다 약 33% 큼.

Base64는 인코딩이지 암호화 아님. 누구나 Base64 문자열을 원래 바이트로 디코딩 가능. 비밀 숨기기에 사용 금지 — 기밀이 필요하면 실제 암호 알고리즘 사용.

URL-safe vs 표준

표준 Base64는 '+'와 '/' 포함, URL에서 특별한 의미 가지므로 퍼센트 인코딩 필요. URL-safe Base64(RFC 4648 §5)는 '+'를 '-'로, '/'를 '_'로 대체하고 후행 '=' 패딩 제거. JWT, OAuth 토큰, 많은 웹 API가 URL-safe 형식 사용.

JWT나 토큰을 수동 디코딩하면 URL-safe ON. 클래식 이메일이나 PDF 임베디드 데이터 작업이면 OFF. 디코더는 URL-safe ON일 때 양 형식 수용 — 표준 알파벳이 특별 쌍 빼고 슈퍼셋이기 때문.

UTF-8 처리

옛 브라우저 btoa()는 ASCII만 처리 가능. 본 도구는 TextEncoder로 입력을 먼저 UTF-8 바이트로 변환 후 그 바이트를 Base64 인코딩. 이로써 이모지, CJK 문자, 강세 라틴, 기타 유니코드 모두 올바르게 인코딩 및 왕복. 바이트-그-다음-base64 접근은 JWT 라이브러리와 대부분 현대 프레임워크와 동일.

자주 묻는 질문

›Base64는 암호화?

아니오. 이진을 ASCII 텍스트로 인코딩하는 방식. 누구나 디코딩 가능. 비밀에는 실제 암호화(AES, RSA 등) 사용.

›왜 URL-safe 다름?

표준 Base64는 URL에서 특별 의미 가져 퍼센트 인코딩 필요한 '+'와 '/' 사용. URL-safe Base64는 '-'와 '_' 대체로 회피.

›JWT 서명 디코딩 가능?

서명 디코딩은 서명의 원시 바이트 제공, 그러나 검증용으로 의도, 사람 읽기 아님. JWT의 헤더와 페이로드(처음 두 세그먼트) 디코딩해 데이터 확인.

›이진 파일에 작동?

직접 안 됨 — 텍스트만 붙여넣기. 파일은 이진 인식 도구 사용. (대부분 브라우저는 작은 파일에 DevTools 사용 가능한 atob/btoa 쌍 내장.)

›왜 디코딩된 텍스트가 깨짐?

입력이 유효 Base64 아니거나 UTF-8 아닌 바이트 인코딩(예: Latin-1 파일). 원래 인코딩 검증. '텍스트로' 디코딩 도구는 UTF-8 가정.

›데이터가 전송되나요?

전송되지 않습니다. 인코딩과 디코딩이 완전히 브라우저에서 실행.

›크기 오버헤드?

원본 바이트보다 약 33% 큼(입력 3 바이트마다 출력 4 문자). 패딩 없는 URL-safe도 같은 오버헤드.

›왜 패딩 중요?

표준 Base64는 길이가 4의 배수 되도록 끝에 '=' 패딩. URL-safe 버전은 디코딩에 필요 없어 종종 생략.