W WorkKit

Base64 인코더·디코더

텍스트와 이미지를 Base64로 인코딩하거나 디코딩합니다. 이미지는 데이터 URI로 변환됩니다.

원본

텍스트를 입력하거나, 이미지를 붙여넣기(Ctrl+V)·끌어다 놓으면 자동으로 인식합니다.

출력 형식

URL이나 파일명에 넣을 값이면 URL-safe 를 고르세요.

계산 방법

Base64는 아무 데이터나 영문·숫자·기호 64자만으로 표현하는 방법입니다. 이메일 첨부나 데이터 URL처럼 텍스트만 통과하는 통로로 데이터를 보내야 할 때 씁니다.

한글이 깨지는 문제는 여기서 나옵니다. 브라우저의 btoa는 문자 하나를 1바이트로 보는데, 한글은 UTF-8에서 3바이트입니다. 그래서 한글을 그대로 넣으면 오류가 나거나 깨집니다. 이 도구는 텍스트를 먼저 UTF-8 바이트로 바꾼 뒤 인코딩하므로 한글과 이모지가 그대로 살아납니다.

URL-safe는 결과에 들어가는 +/-_로 바꾸고 끝의 패딩을 뺀 형태입니다. 이 두 글자가 URL 경로나 쿼리에서 다른 뜻을 가지기 때문이며, JWT 토큰이 이 방식을 씁니다. 디코딩은 두 형식을 모두 받습니다.

이미지도 Base64로 바꿀 수 있습니다. 인코딩에서 "이미지"를 고르고 파일을 올리면 data:image/png;base64,… 형태의 데이터 URI가 나옵니다. 이걸 HTML의 <img src>나 CSS url()에 붙이면 별도 파일 없이 이미지가 표시됩니다. 작은 아이콘을 인라인으로 심어 요청 수를 줄일 때 유용하지만, Base64는 원본보다 약 33% 커지므로 큰 이미지에는 맞지 않습니다.

마지막으로 하나. Base64는 암호화가 아닙니다. 누구나 한 번에 되돌릴 수 있는 인코딩일 뿐이라, 비밀번호나 API 키를 Base64로 바꿔 두는 것은 그대로 노출한 것과 같습니다.

자주 묻는 질문

Q다른 사이트에서는 한글이 깨지는데요?
A브라우저의 btoa 함수가 문자 하나를 1바이트로 보기 때문입니다. 한글은 UTF-8에서 3바이트라 그대로 넣으면 오류가 나거나 깨집니다. 이 도구는 텍스트를 UTF-8 바이트로 바꾼 뒤 인코딩하므로 한글과 이모지가 정상 처리됩니다.
QURL-safe는 언제 쓰나요?
ABase64 결과에 들어가는 +와 /는 URL이나 파일명에서 다른 뜻을 가집니다. URL-safe는 이를 -와 _로 바꾸고 끝의 = 패딩을 뺍니다. JWT 토큰이 이 방식을 씁니다.
Q디코딩할 때 패딩(=)이 없어도 되나요?
A됩니다. 패딩이 빠졌거나 중간에 줄바꿈이 섞여 있어도 알아서 처리합니다.
QBase64는 암호화인가요?
A아닙니다. 누구나 되돌릴 수 있는 인코딩일 뿐입니다. 비밀번호나 API 키를 Base64로 바꿔 두는 것은 보안 조치가 아니며, 그대로 노출된 것과 같습니다.
Q이미지도 Base64로 바꿀 수 있나요?
A됩니다. 인코딩 상태에서 입력창에 이미지를 붙여넣기(Ctrl+V)하거나 끌어다 놓으면 자동으로 인식해 데이터 URI를 만듭니다. HTML의 <img src>나 CSS url()에 그대로 붙여 넣으면 파일 없이 이미지가 표시됩니다.
Q데이터 URI와 순수 Base64는 뭐가 다른가요?
A데이터 URI는 "data:image/png;base64," 접두사가 붙은 전체 문자열로, 그대로 이미지로 인식됩니다. 순수 Base64는 접두사 없이 인코딩된 값만 있는 형태로, JSON 필드 등에 값만 담을 때 씁니다.
QBase64를 다시 이미지로 되돌릴 수 있나요?
A됩니다. 디코딩에 데이터 URI나 이미지 Base64를 넣으면 텍스트가 아니라 이미지로 인식해 미리보기와 저장 버튼을 보여줍니다. 데이터 URI 접두사가 없어도 앞부분 바이트로 형식(PNG·JPG 등)을 알아냅니다.
Q이미지를 Base64로 바꾸면 용량이 늘어나지 않나요?
A늘어납니다. Base64는 원본보다 약 33% 커집니다. 작은 아이콘이라면 요청 수를 줄이는 이점이 크지만, 큰 이미지는 데이터 URI로 심는 것이 오히려 손해일 수 있습니다.