🔣 Base64 인코더/디코더

변환 방향

🔒 인코딩텍스트 → Base64 🔓 디코딩Base64 → 텍스트·파일

원본 텍스트 URL-safe 형식으로 출력 (+/ 대신 -_ 사용, = 생략 · URL·JWT용)

원본 텍스트는 100만 자, 디코딩할 Base64 문자열은 800만 자까지 처리합니다.

Base64 결과

🤔 Base64 인코딩 관련 Q&A

Base64 인코딩이란 무엇인가요?

Base64는 이미지 파일, 실행 파일, 일반 문자열 같은 8비트 이진 데이터를 알파벳 대소문자, 숫자, +, /의 64개 문자로 바꿔 표현하는 방식입니다. 3바이트를 4글자로 바꾸기 때문에 결과는 원본보다 약 33% 길어지고, 길이를 4의 배수로 맞추기 위해 끝에 = 패딩이 붙을 수 있습니다. 텍스트만 허용하는 이메일 본문, JSON, HTML 속성 안에 바이너리 데이터를 넣을 때 쓰이지만, 암호화나 전송 보안을 제공하지는 않습니다. 한글처럼 ASCII 밖의 문자는 먼저 UTF-8 바이트로 바꾼 뒤 인코딩하므로 한 글자가 3바이트로 계산됩니다.

Base64는 암호화 방식인가요?

아닙니다. Base64는 '인코딩(Encoding)' 방식일 뿐, 보안을 위한 '암호화(Encryption)'가 아닙니다. 누구나 Base64 문자열을 원본 데이터로 다시 디코딩할 수 있으므로, 비밀번호나 개인정보 같은 민감한 데이터는 Base64로만 처리해서 노출하면 안전하지 않습니다. 반드시 강력한 암호화 알고리즘 처리를 별도로 해야 합니다.

URL-safe Base64와 JWT는 어떻게 처리하나요?

표준 Base64의 +와 /는 URL에서 특별한 의미를 가지므로, URL·파일 이름·JWT 토큰에서는 이를 -와 _로 바꾸고 끝의 =를 생략한 URL-safe 형식을 씁니다. 디코딩할 때는 두 형식을 자동으로 구분하고, 빠진 패딩과 줄바꿈·공백, data:image/png;base64, 같은 접두어도 알아서 정리합니다. 점(.)으로 나뉜 세 부분으로 된 JWT를 붙여넣으면 헤더와 페이로드를 각각 JSON으로 풀어 보여 줍니다. 다만 서명은 검증하지 않으므로 토큰이 위조되지 않았다는 보장은 되지 않습니다.

디코딩 결과가 '바이너리 데이터'로 나오는 이유는 무엇인가요?

디코딩한 바이트가 올바른 UTF-8 텍스트가 아니면 억지로 글자로 바꾸지 않고 바이너리 데이터로 안내합니다. 이미지나 PDF를 Base64로 만든 문자열이라면 파일 머리 부분의 식별 바이트로 PNG·JPEG·GIF·WebP·PDF·ZIP 등의 형식을 판별해 알맞은 확장자로 저장할 수 있게 합니다. 텍스트였어야 하는데 바이너리로 나온다면 복사 과정에서 문자열 일부가 잘렸거나, UTF-8이 아닌 EUC-KR 등 다른 인코딩으로 만들어진 문자열일 가능성이 큽니다.

이미지를 Base64로 언제 주로 변환하나요?

HTML 문서나 이메일 템플릿 안에 작은 로고 이미지나 아이콘을 직접 넣을 때 주로 사용합니다. 파일 탭에서 이미지를 고른 뒤 복사 형식을 'HTML <img> 태그'나 'CSS background-image'로 바꾸면 <img src="data:image/png;base64,..."> 형태를 바로 붙여넣을 수 있습니다. 별도의 이미지 요청이 줄어드는 대신 문서 자체가 커지고 브라우저 캐시를 따로 활용하지 못하므로, 수 킬로바이트 이하의 작은 이미지에만 권장됩니다.

지원 범위와 주의할 한계는 무엇인가요?

텍스트 입력은 최대 100만 자, Base64 디코딩 입력은 최대 800만 자, 파일은 형식과 관계없이 최대 10MB까지 처리합니다. 결과가 매우 길면 화면에는 앞부분만 미리 보여 주고, 복사와 저장 버튼은 전체 결과를 사용합니다. Base64 결과는 원본보다 약 33% 커지므로 큰 파일 전송이나 저장 용도로는 적합하지 않습니다. 모든 변환은 브라우저 안에서 처리되며 입력한 텍스트나 파일을 서버로 업로드하지 않습니다.