Base64 인코딩
텍스트와 파일을 Base64로 인코딩·디코딩해요. 이미지 결과는 미리보기로 확인 가능해요.
디코딩은 공백·개행·URL-safe 문자·빠진 패딩을 알아서 처리해요.
이럴 때 쓰세요
이렇게 사용하세요
결과가 예상과 다를 때
파일이 열리지 않아요
지원하는 형식인지 확인해 주세요. 암호가 걸린 파일은 암호를 푼 뒤 다시 시도하면 돼요.
결과가 마음에 안 들어요
원본은 그대로예요. 옵션이나 프리셋을 바꿔 다시 시도할 수 있어요.
자주 하는 실수
- Base64는 암호화가 아니라 인코딩입니다. 키 없이 되돌릴 수 있으므로 비밀번호나 개인정보를 담으면 그대로 드러납니다. 전송이 필요하면 HTTPS나 실제 암호화를 쓰세요.
- URL과 쿼리 파라미터에 넣을 때는 URL-safe 모드로 바꿔야 합니다. 표준 알파벳의 덧셈 기호와 슬래시가 쿼리에서 공백과 경로 구분자로 오인돼 값이 깨집니다.
- 한글 텍스트를 인코딩한 뒤 문자열로 디코딩하면 글자가 깨집니다. 바이트열을 UTF-8로 해석해야 원문이 나오므로 디코딩할 때 문자 인코딩을 반드시 명시하세요.
- 이진 파일은 바이트 단위 그대로 변환해야 합니다. 줄바꿈 두 글자를 한 글자로 바꾸거나 앞뒤에 표시용 표식을 섞으면 원본과 달라져 이미지가 깨집니다.
계산 근거
표준은 RFC 4648 제4절입니다. 3바이트(24비트)를 6비트씩 잘라 총 64개 문자(A~Z, a~z, 0~9, +, /)에 대응시키고, 남는 바이트는 등호로 채워 길이를 4의 배수로 맞춥니다. 결과 문자열 길이는 원본 바이트 수의 약 4분의 3이며, RFC 4648 제5절의 URL-safe 변형은 덧셈과 슬래시를 빼고 등호 패딩을 제거합니다. 데이터를 줄이는 방법이 아니라 형식을 바꾸는 방법입니다.
실제로 계산해 보면
'Hello'를 Base64로 바꾸면?
SGVsbG8=입니다. 5바이트를 4글자 단위로 채워 8자리가 되고, 남은 1바이트를 등호 두 개로 채웠습니다. 6바이트인 '안녕'은 7JWI64WV로 8자리가 됩니다.
1MB 파일을 Base64로 만들면 몇 MB가 되나요?
4×⌈1,048,576÷3⌉ = 1,398,104바이트로 약 1.40MB입니다. 정확히 3분의 1만큼 커지므로 용량이 중요한 곳에서는 원본 파일을 그대로 쓰는 편이 낫습니다.
왜 등호가 0개, 1개, 2개일 수 있나요?
바이트 수를 3으로 나눈 나머지가 1이면 등호 두 개, 2이면 한 개, 0이면 없습니다. 'A'는 1바이트라 QQ==, 'AB'는 2바이트라 QUI=, 'Hello'는 5바이트라 SGVsbG8=입니다.
더 궁금한 것
JWT는 어떻게 읽나요?
헤이더·페이로드·서명 세 부분을 점으로 이은 구조고 앞의 둘은 JSON을 URL-safe Base64로 인코딩한 것입니다. Base64url은 알파벳이 빼기와 밑줄로 바뀌고 등호가 없으므로 표준 모드로 읽으면 깨집니다. 서명 검증 없이 페이로드만 읽는 것은 보안 확인이 아닙니다.
Base64 이미지 값을 HTML에 바로 넣어도 되나요?
데이터 URL 형식(data:image/png;base64,...)으로 넣으면 별도 요청 없이 표시되지만 문서 크기가 3분의 1 늘고 브라우저가 다시 디코딩해야 합니다. 캐싱과 CDN 효과를 잃으므로 캐시 가능한 파일은 경로로 참조하세요.
메타데이터도 같이 들어 있나요?
문자열 전체를 인코딩하므로 파일 안의 촬영 정보나 위치 좌표까지 함께 들어갑니다. 공개 전에는 인코딩하기 전에 메타데이터를 지워야 합니다.
알아둘 경계값
- URL-safe 모드는 끝 등호를 떼어요. 4의 배수가 아니면 받는 쪽에서 등호를 채워야 디코딩돼요.
- 디코딩은 하이픈·밑줄을 자동 표준 문자로 고쳐요. 표준·URL-safe가 섞여도 구분 없이 읽어요.
- 텍스트가 아닌 결과는 바이트 수만 나와요. 내용은 파일로 저장해야 확인되니 디코딩 뒤 저장을 누르세요.
- 파일 인코딩은 전체를 한 번에 읽어요. 큰 파일은 메모리를 많이 쓰고 실패 시 안내만 나와요.
- 바꾸기 버튼은 입력·출력을 맞바꿔요. 편하지만 실수로 누르면 내용이 뒤집혀요.
- 공백·줄바꿈은 디코딩 전에 제거돼요. 여러 줄도 이어 읽지만 중간 한글은 오류로 처리돼요.
결과를 믿기 전 확인 목록
- 상대가 표준 모드인지 URL-safe인지 먼저 확인하세요. 다르면 덧셈·슬래시에서 깨져요.
- 토큰·URL 파라미터는 URL-safe로 인코딩하세요. 표준 모드 덧셈 기호는 쿼리에서 공백으로 읽혀요.
- 결과 길이가 원본보다 약 3분의 1 늘어나는지 보세요. 용량 제한이 있다면 인코딩 전 크기를 재세요.
- 디코딩 결과가 바이트 수 안내라면 텍스트가 아니에요. 복사 말고 파일로 저장해 확인하세요.
- 인코딩은 암호화가 아니라는 점을 기억하세요. 누구나 되돌릴 수 있어 전송 시 별도 보호가 필요해요.
- 이미지 데이터 URL은 앞에 형식을 붙여야 보여요. 인코딩 결과만으로 브라우저가 그림으로 인식하지 않아요.
- 파일 변환 전 모드를 확인하세요. 읽는 순간 인코딩돼 나중에 바꿔도 다시 읽어야 해요.
- 긴 문자열은 중간이 잘렸는지 길이를 대조하세요. 4의 배수에서 벗어나면 등호 보정이 필요해요.
- 서명·인증 값은 내용 확인용으로만 쓰세요. 디코딩 성공이 위조 검증이 되지는 않으니 서버 검증을 거치세요.
자주 묻는 질문
파일도 변환되나요?
네. 파일 선택 시 브라우저 안에서 읽어 Data URL로 변환합니다.
URL-safe 모드는 언제 쓰나요?
JWT, OAuth 토큰, URL 파라미터처럼 +와 /가 문제되는 곳에 씁니다. 표준 모드는 일반 API·이메일용이에요.