Base64는 임의의 바이너리 데이터를 ASCII 문자 64개만으로 표현하는 인코딩입니다. 이미지 파일을 HTML에 직접 넣을 때, HTTP 헤더에 인증 정보를 실을 때, JSON 안에 파일을 담아 보낼 때처럼 '텍스트만 통과하는 통로'로 바이너리를 보내야 할 때 씁니다.
이 도구는 텍스트 인코딩·디코딩은 물론 파일을 Base64와 Data URI로 변환하는 기능, 그리고 URL 인코딩(encodeURIComponent·encodeURI)까지 한 화면에서 제공합니다. 한글이나 이모지가 섞여도 UTF-8로 정확히 처리하며, JWT나 URL 파라미터에 쓰이는 URL-safe(base64url) 변형도 지원합니다.
사용 방법
- 모드 선택 — 상단에서 텍스트, 파일 → Base64, URL 인코딩 중 하나를 고릅니다. 텍스트 모드는 인코딩과 디코딩을 서로 바꿔 가며 쓸 수 있고, 서로 바꾸기 버튼을 누르면 결과가 입력으로 옮겨집니다.
- 옵션 조정 — URL-safe를 켜면
+·/가-·_로 바뀌고 패딩이 제거됩니다. JWT나 쿼리 파라미터에 값을 실을 때 필요합니다. 76자마다 줄바꿈은 이메일(MIME) 규격에 맞춰야 할 때 사용합니다. - 파일 변환 — 파일 모드에서 파일을 끌어다 놓거나 선택하면 Base64 문자열과
data:URI가 함께 생성됩니다. 이미지라면 미리보기도 표시됩니다. 파일은 브라우저 메모리에서만 읽히며 업로드되지 않습니다. - 결과 복사·저장 — 각 패널의 복사 버튼으로 클립보드에 담거나 다운로드 버튼으로 텍스트 파일로 저장합니다. Data URI는 길이가 매우 길어질 수 있으므로 미리보기에서는 앞부분만 표시됩니다.
자주 묻는 질문
Base64는 암호화인가요?
아닙니다. Base64는 인코딩이며 누구나 되돌릴 수 있습니다.
비밀번호나 API 키를 Base64로 바꿔 저장하는 것은 보안 조치가 아니라 그저 눈에 덜 띄게 하는 것뿐입니다. HTTP Basic 인증이 Authorization: Basic <base64> 형태를 쓰는 것도 암호화 목적이 아니라 콜론이 포함된 문자열을 헤더에 안전하게 싣기 위해서이며, 그래서 Basic 인증은 반드시 HTTPS 위에서만 써야 합니다. 실제 기밀 유지가 필요하면 AES 같은 암호화를 사용하세요.
한글을 인코딩했다가 디코딩하면 깨지는 경우가 있습니다.
이 도구는 UTF-8로 인코딩하므로 한글·이모지 모두 정확히 왕복합니다.
깨진다면 다른 쪽 시스템의 인코딩이 다를 가능성이 큽니다. 예를 들어 예전 자바스크립트의 btoa() 는 Latin-1만 처리해 한글을 넣으면 예외가 발생하고, PHP나 Java에서 인코딩을 명시하지 않으면 시스템 기본 문자셋(EUC-KR 등)으로 바이트를 만들 수 있습니다. Base64는 바이트 단위 변환이므로, 원본을 어떤 문자 인코딩으로 바이트화했는지를 양쪽이 맞춰야 합니다.
이미지를 Data URI로 넣으면 좋은가요?
작은 아이콘이라면 유용하지만 큰 이미지에는 권하지 않습니다.
Base64로 바꾸면 데이터 크기가 약 33% 늘어납니다. 또 Data URI로 인라인된 이미지는 브라우저가 별도로 캐시하지 못하므로, 그 이미지를 포함한 HTML이나 CSS 파일 전체를 매번 다시 받게 됩니다. 수 KB 이하의 아이콘·로고를 인라인해 요청 수를 줄이는 정도가 적정선이고, 사진처럼 큰 파일은 별도 리소스로 두고 캐시 헤더를 활용하는 편이 훨씬 빠릅니다.
알아두면 좋은 개념
3바이트를 4문자로: Base64의 원리
Base64는 입력 바이트를 3개씩 묶어 24비트로 만든 뒤, 이를 6비트씩 네 조각으로 잘라 각각을 64개 문자(A-Z, a-z, 0-9, +, /) 중 하나에 대응시킵니다. 6비트로 표현할 수 있는 값이 정확히 64가지이기 때문입니다.
입력 길이가 3의 배수가 아니면 마지막 묶음이 모자라는데, 이때 = 패딩을 붙여 4문자 단위를 맞춥니다. 결과 길이는 항상 원본의 약 4/3이 되며, 이것이 Base64가 33% 커지는 이유입니다.
base64url — URL에서 쓰는 변형
표준 Base64의 + 와 / 는 URL에서 각각 공백과 경로 구분자로 해석될 수 있고, = 는 쿼리스트링에서 키-값 구분자와 충돌합니다. 그래서 RFC 4648은 +→-, /→_ 로 바꾸고 패딩을 생략하는 base64url 변형을 정의했습니다.
JWT의 세 조각, OAuth의 PKCE code_challenge, WebAuthn의 자격증명 ID가 모두 이 방식을 씁니다. 표준 Base64 디코더에 base64url 문자열을 그대로 넣으면 실패하므로 변환이 필요하며, 이 도구의 디코더는 두 형식을 모두 자동으로 받아들입니다.
URL 인코딩은 Base64와 다른 문제
URL 인코딩(퍼센트 인코딩)은 URL에서 특별한 의미를 가진 문자를 %XX 형태로 바꾸는 방식입니다. Base64와 목적이 전혀 다릅니다.
encodeURIComponent 는 /·?·&·= 까지 모두 인코딩하므로 쿼리 파라미터의 값 하나를 감쌀 때 씁니다. encodeURI 는 URL 전체 구조를 보존해야 할 때 쓰며 이런 구분자들은 그대로 둡니다. 쿼리 값에 encodeURI 를 쓰면 값 안의 & 가 파라미터 구분자로 오인되어 데이터가 잘리는 버그가 생기니, 값 단위에는 항상 encodeURIComponent 를 쓰세요.