본문으로 건너뛰기
bobob

Base64 인코더·디코더

텍스트, Base64, Base64URL, 이미지 data URL, JSON payload, JWT segment를 로컬에서 변환하고 복사 전 구조를 확인하는 도구예요.

브라우저에서만 처리입력값이 서버로 가지 않아요.

입력과 결과

입력한 내용은 이 브라우저에만 저장돼요. 다시 열면 마지막 작업을 불러올 수 있어요.

이럴 때 써요

  • 텍스트, Base64, Base64URL, 이미지 data URL, JSON payload, JWT segment를 로컬에서 변환하고 복사 전 구조를 확인하는 도구예요.
  • 브라우저 로컬 방식으로 입력을 다루며 복사 전 결과를 확인해요.
  • Base64 인코더·디코더와 관련 도구를 이어서 사용해 작업 흐름을 줄여요.

예제

일반 입력
hello world
Base64 인코더·디코더를 사용하기 전에 이 예제로 입력 흐름을 확인하세요.
일반 출력
aGVsbG8gd29ybGQ=
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
추가 예제
eyJzdGF0dXMiOiJvayIsInNjb3BlIjoicmVhZCJ9
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
추가 예제
data:image/png;base64,iVBORw0KGgo=
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.

자주 하는 실수

  • URL-safe Base64와 표준 Base64는 padding과 문자셋이 달라 그대로 섞으면 실패할 수 있어요.
  • 디코딩 결과가 사람이 읽히지 않으면 UTF-8 텍스트가 아니라 binary/압축/이미지 데이터일 수 있고, JWT payload segment는 token 맥락 없이 보면 잘못 판단할 수 있어요.
  • 복사한 값에 운영 비밀값, 고객 데이터, 내부 URL이 섞여 있으면 공유 전에 제거해야 해요.

복사하기 전에

  1. 1encode/decode 모드가 대상 값의 방향과 맞는지 먼저 확인해요.
  2. 2진단 패널에서 JSON key, JWT-like payload, 이미지 preview, padding, 제어 문자, credential/cookie/API key 노출 여부를 확인해요.
  3. 3Base64 인코더·디코더 결과가 다음 단계에 맞는지 관련 도구로 이어서 검토해요.

참고 자료

  • 표준 Base64 와 URL 용 Base64 는 알파벳이 달라요

    RFC 4648 은 62·63번째 문자로 표준에서는 + 와 / 를, base64url 에서는 - 와 _ 를 쓰도록 정해요. URL·쿠키·경로에 표준 Base64 를 그대로 넣으면 / 는 경로 구분으로, + 는 공백으로 해석돼요.

    기준 RFC 4648

  • JWT 조각에는 패딩 = 이 없어요

    JWS 는 base64url 에서 패딩을 모두 떼도록 규정해요(RFC 7515 의 BASE64URL 정의). 그래서 JWT 조각을 표준 Base64 디코더에 넣으면 길이가 4의 배수가 아니라며 실패해요.

    기준 RFC 7515

  • Base64 는 암호화가 아니에요

    RFC 4648 은 Base64 를 데이터 인코딩으로 정의해요 — 키 없이 누구나 되돌릴 수 있어요. 토큰이나 비밀값을 Base64 로 감싸는 건 숨기는 게 아니라 한 단계 귀찮게 만드는 것뿐이에요.

    기준 RFC 4648

자주 묻는 질문

Base64 인코더·디코더 입력값은 어디에서 처리되나요?

가능한 작업은 브라우저에서 처리돼요. 운영 비밀값이나 고객 데이터는 넣지 않는 기준은 그대로 유지하세요.

결과를 그대로 운영에 써도 되나요?

복사하기 전에 대상 런타임, 인코딩, 시간대, 보안 정책처럼 환경별 차이를 한 번 더 확인하세요.