Base64
바이너리나 텍스트를 운반하기 쉬운 문자 조합으로 바꿉니다. 데이터 자체를 다른 표기로 변환하는 데 가깝습니다.
Difference
한 줄로 구분하면
URL 인코딩
URL 안에서 의미가 깨질 수 있는 문자만 이스케이프합니다. 원래 문자열을 URL 문법에 맞게 안전하게 보내는 데 가깝습니다.
서로 대체 불가
쿼리 파라미터를 Base64만 해서 해결되는 것도 아니고, 바이너리 파일을 URL 인코딩으로 보내는 것도 맞지 않습니다.
Difference
The shortest way to distinguish them
Base64
Turns binary or text into a transport-friendly character sequence. It is mainly a representation change.
URL encoding
Escapes characters that would break URL parsing. It preserves meaning inside a URL rather than transforming the data model itself.
Not interchangeable
Encoding query params with Base64 alone is not the same as making them URL-safe, and URL encoding is not a substitute for binary-to-text transport.
Use Cases
언제 무엇을 써야 하나
JWT, 쿠키, 헤더 payload
구조화된 값이나 바이너리 조각을 문자열로 실어야 할 때는 Base64가 더 자주 나옵니다. 다만 URL 경로로 넘길 땐 URL-safe 변형까지 고려해야 합니다.
쿼리 파라미터, 리디렉션 URL
공백, 한글, 예약 문자 때문에 URL이 깨질 수 있는 상황이면 URL 인코딩이 먼저입니다. 특히 OAuth 콜백이나 결제 리턴 URL에서 자주 중요합니다.
둘 다 필요한 경우
일부 시스템은 먼저 Base64로 구조를 바꾼 뒤, 그 값을 다시 URL 파라미터에 실어 보냅니다. 이럴 때는 어느 단계에서 실패했는지 순서를 나눠서 봐야 합니다.
Use Cases
When to use which one
JWTs, cookies, header payloads
Base64 shows up often when structured or binary data needs to travel as text. If it later moves through a URL, URL-safe variants may still matter.
Query params and redirects
URL encoding comes first when spaces, Korean text, or reserved characters can break a callback or redirect chain.
Stacks that use both
Some systems Base64-encode a value first and then place it in a query parameter. Debugging gets easier when you identify which layer transformed the value.
Workflow
이 사이트에서 바로 같이 볼 페이지
- 문자열이나 파일을 변환할 때는 Base64 변환기를 먼저 엽니다.
- 쿼리 파라미터와 리디렉션 주소를 점검할 때는 URL 인코더/디코더를 같이 엽니다.
- 키-값 행으로 공유 링크를 조립해야 하면 URL 쿼리 생성기를 이어서 봅니다.
Workflow
The pages to open next
- Open the Base64 converter when the value itself needs representation changes.
- Use the URL encoder/decoder when the string is traveling through a query, redirect, or callback.
- When you need to assemble a final shareable link, move into the URL Query Builder.