CodeKitHub이 도구는 무엇인가요?
Base64는 이진 데이터나 텍스트 데이터를 안전한 64개의 ASCII 문자 집합(A–Z, a–z, 0–9, +, /)으로 변환하는 인코딩 방식입니다. HTML/CSS에 이미지를 삽입할 때, HTTP 기본 인증 헤더, 이메일 첨부파일(MIME), JSON 웹 토큰, 텍스트만 다룰 수 있는 채널을 통과해야 하는 API 페이로드 등 소프트웨어 전반에서 사용됩니다.
중요: Base64는 암호화가 아니라 인코딩입니다. 누구나 디코딩할 수 있습니다. Base64의 목적은 데이터를 비밀로 감추는 것이 아니라, 텍스트만 이해하는 시스템을 통해 안전하게 전송할 수 있게 만드는 것입니다.
Base64는 RFC 4648에 공식적으로 규정되어 있으며, 이 문서는 JWT나 웹 API에서 쓰이는 URL 안전 변형도 함께 정의합니다. +는 -로, /는 _로 치환해 퍼센트 인코딩 없이도 인코딩된 문자열이 URL 안에서 안전하게 이동할 수 있도록 합니다.
왜 사용해야 할까요?
- API 토큰, JWT 세그먼트, 인증 헤더를 디코딩해 안의 내용을 확인.
- 데이터 URI, 설정 파일, HTTP 헤더용 텍스트를 인코딩.
- UTF-8 안전: 이모지와 비라틴 문자도 정확히 인코딩·디코딩.
- 100% 비공개 — 변환이 브라우저 안에서 이루어지며 어디에도 업로드되지 않습니다.
- 무료, 로그인 불필요, 크기 제한 없음.
사용 방법
- 입력창에 내용을 입력하거나 붙여넣으세요.
- "인코딩"을 클릭해 텍스트를 Base64로 변환하거나, "디코딩"을 클릭해 Base64를 텍스트로 되돌리세요.
- 디코딩이 실패하면 입력값이 올바른 Base64가 아닙니다—문자가 빠졌거나 공백이 섞이지 않았는지 확인하세요.
- "복사"를 클릭해 결과를 복사하세요.
예시
입력
Hello, CodeKitHub! 안녕 👋결과
SGVsbG8sIENvZGVLaXRIdWIhIOyViOugle+8jPCfkYs=한글과 이모지가 왕복 변환에서도 그대로 유지되는 걸 확인해 보세요—이게 바로 UTF-8 안전 처리의 핵심입니다.
실전 활용 팁
- JWT 토큰은 점으로 구분된 세 개의 Base64 세그먼트로 이루어져 있습니다—첫 번째(헤더)와 두 번째(페이로드)를 각각 디코딩해 확인하세요. 세 번째는 이진 서명이라 알아볼 수 없는 문자로 나옵니다.
- JWT 세그먼트 디코딩이 실패한다면 base64url 인코딩일 가능성이 큽니다. 표준 도구는 +/ 알파벳을 기대하므로, 먼저 -를 +로, _를 /로 바꿔 보세요.
- Base64 문자열 안의 공백이나 줄바꿈은 대개 이메일이나 로그에서 남은 무해한 흔적이지만, 마지막 = 패딩이 빠진 경우는 문제일 때가 많습니다—데이터가 손상됐다고 단정하기 전에 먼저 길이를 확인해 보세요.
- Base64는 데이터 크기를 약 33% 늘립니다. 작은 데이터에는 문제없지만, 몇 KB를 넘는 이미지라면 데이터 URI보다 실제 파일을 쓰는 편이 거의 항상 낫습니다.
실제 활용 사례
이 도구를 찾는 사람들이 매일 마주치는 세 가지 상황이 있습니다. Authorization 헤더나 JWT 안의 내용을 확인하는 경우, Base64로 감싸져 도착한 웹훅·API 페이로드 필드를 디코딩하는 경우(보통 JSON이므로 디코딩 후 포맷을 정리해 주세요), 디버깅 중에 데이터 URI나 Basic-Auth 문자열을 직접 만들어야 하는 경우입니다.
이미지나 파일 같은 이진 데이터의 경우, 텍스트로 디코딩했을 때 알아볼 수 없는 문자(모지바케)가 나오는 게 정상이라는 점을 기억하세요—데이터 자체는 완전히 유효할 수 있고, 단지 텍스트가 아닐 뿐입니다. 이진 데이터의 인코딩·디코딩은 코드 안에서 처리하는 것이 맞으며, 이 도구는 텍스트 위주 상황에 최적화되어 있습니다.
디코딩 실패 원인 진단하기
Base64 디코딩 실패는 거의 항상 세 가지 원인 중 하나로 귀결됩니다. 빈도순으로 나열하면, 첫째는 입력값이 실제로는 base64url(JWT나 URL 안전 문맥에서 흔한, +와 / 대신 -와 _를 쓰는 방식)이라 표준 디코딩이 받아들이기 전에 문자를 다시 바꿔줘야 하는 경우입니다. 둘째는 문자열이 어딘가에서 잘려나간 경우(마지막 몇 글자를 놓친 복사-붙여넣기, 혹은 중간에 잘린 로그 줄)로, 패딩까지 고려했을 때 올바른 Base64 문자열의 길이는 항상 4의 배수라는 점으로 감지할 수 있습니다. 셋째는 복사 과정에서 불필요한 문자(여분의 공백, 우연히 들어간 줄바꿈, 실수로 중복된 문자)가 섞여 들어간 경우로, 원본 소스에서 다시 타이핑하지 않고 직접 붙여넣는 것이 항상 더 안전한 이유이기도 합니다.
→ JSON 포맷터 · URL 인코더 / 디코더 · JWT 디코더
자주 묻는 질문
Base64는 암호화인가요?
아닙니다. Base64는 누구나 디코딩할 수 있는 가역적인 인코딩 방식으로, 보안성은 전혀 없습니다. 데이터를 보호해야 한다면 AES 같은 실제 암호화를 사용하세요. Base64는 어디까지나 데이터를 텍스트로 안전하게 전송하기 위한 용도입니다.
디코딩한 결과가 알아볼 수 없는 문자로 나오는 이유는 무엇인가요?
입력값이 실제로 Base64가 아니거나, 잘려나갔거나, 원본 데이터가 텍스트가 아니라 이미지 같은 이진 데이터였을 가능성이 있습니다. 이진 데이터는 읽을 수 있는 문자로 표시되지 않습니다.
끝에 붙는 = 기호는 무엇인가요?
패딩(padding)입니다. Base64는 입력 3바이트를 4개의 출력 문자로 바꾸는 블록 단위로 동작합니다. 입력 길이가 3으로 나누어 떨어지지 않으면 마지막 블록을 채우기 위해 = 문자가 하나 또는 두 개 추가됩니다.
이 도구는 이모지나 한글도 잘 처리하나요?
네. 텍스트를 먼저 UTF-8 바이트로 인코딩하는데, 이것이 표준적인 방식입니다. btoa()를 그대로 사용하는 단순한 도구들은 Latin-1 범위를 벗어난 문자에서 오류가 나지만, 이 도구는 그렇지 않습니다.
제 데이터가 어딘가에 업로드되나요?
아니요. 인코딩과 디코딩은 전부 브라우저 안에서 자바스크립트로 처리됩니다. 입력한 데이터는 기기 밖으로 나가지 않습니다.