도구 목록으로

Base64 vs URL 인코딩 가이드

🔒 브라우저 내부 처리

둘 다 문자열을 “안전하게 바꾼다”는 느낌이 있지만, Base64와 URL 인코딩은 완전히 다른 목적과 실패 지점을 갖습니다.

Difference

한 줄로 구분하면

Base64

바이너리나 텍스트를 운반하기 쉬운 문자 조합으로 바꿉니다. 데이터 자체를 다른 표기로 변환하는 데 가깝습니다.

URL 인코딩

URL 안에서 의미가 깨질 수 있는 문자만 이스케이프합니다. 원래 문자열을 URL 문법에 맞게 안전하게 보내는 데 가깝습니다.

서로 대체 불가

쿼리 파라미터를 Base64만 해서 해결되는 것도 아니고, 바이너리 파일을 URL 인코딩으로 보내는 것도 맞지 않습니다.

Use Cases

언제 무엇을 써야 하나

JWT, 쿠키, 헤더 payload

구조화된 값이나 바이너리 조각을 문자열로 실어야 할 때는 Base64가 더 자주 나옵니다. 다만 URL 경로로 넘길 땐 URL-safe 변형까지 고려해야 합니다.

쿼리 파라미터, 리디렉션 URL

공백, 한글, 예약 문자 때문에 URL이 깨질 수 있는 상황이면 URL 인코딩이 먼저입니다. 특히 OAuth 콜백이나 결제 리턴 URL에서 자주 중요합니다.

둘 다 필요한 경우

일부 시스템은 먼저 Base64로 구조를 바꾼 뒤, 그 값을 다시 URL 파라미터에 실어 보냅니다. 이럴 때는 어느 단계에서 실패했는지 순서를 나눠서 봐야 합니다.

Workflow

이 사이트에서 바로 같이 볼 페이지

  1. 문자열이나 파일을 변환할 때는 Base64 변환기를 먼저 엽니다.
  2. 쿼리 파라미터와 리디렉션 주소를 점검할 때는 URL 인코더/디코더를 같이 엽니다.
  3. 키-값 행으로 공유 링크를 조립해야 하면 URL 쿼리 생성기를 이어서 봅니다.
Base64 변환기 열기 URL 인코더/디코더 URL 쿼리 생성기

Examples

실제 입력과 결과

같은 문자열을 두 방식으로

입력

hello world?

결과

Base64            aGVsbG8gd29ybGQ/
Percent encoding  hello%20world%3F

Base64는 바이트를 다른 문자 집합으로 옮겨 담는 것이고, percent encoding은 URL에서 특별한 뜻을 가진 문자만 바꿉니다. 목적이 다릅니다.

Base64를 URL에 넣을 때

입력

a+b/c=  (표준 Base64)

결과

a-b_c   (URL-safe Base64)
+ -> -,  / -> _,  = 패딩 제거

표준 Base64의 +와 /는 URL에서 다른 의미로 읽힙니다. JWT가 URL-safe 변형을 쓰는 이유입니다.

Troubleshooting

자주 만나는 오류

어느 쪽을 써야 할지 헷갈릴 때

텍스트가 아닌 데이터(이미지, 인증서, 바이너리)를 텍스트만 다니는 통로에 실어야 하면 Base64입니다. URL의 경로나 쿼리에 특수문자를 안전히 넣어야 하면 percent encoding입니다. 둘은 대체재가 아닙니다.

Base64 문자열이 URL에서 깨질 때

표준 Base64의 +가 공백으로, /가 경로 구분자로 해석됩니다. URL-safe Base64로 바꾸거나, Base64 결과를 percent encoding으로 한 번 더 감싸세요. 후자를 쓸 때는 디코딩 순서를 반대로 해야 합니다.

Base64가 암호화라고 오해할 때

Base64는 누구나 되돌릴 수 있는 인코딩입니다. 비밀을 감추는 기능이 전혀 없습니다. Basic 인증 헤더가 Base64인 것도 보안이 아니라 전송 호환성 때문입니다.