URL 인코딩이 필요한 이유
URL은 ASCII 문자만 안전하게 전송할 수 있도록 RFC 3986으로 표준화되어 있습니다. 한글·이모지·공백·특수문자(?, &, =, /)는 그대로 사용하면 URL 파싱이 깨지거나 의미가 잘못 전달되므로% 다음 두 자리 16진수 형식(퍼센트 인코딩, percent-encoding)으로 변환해야 합니다. 예를 들어 "안녕"은 UTF-8로 변환된 후 %EC%95%88%EB%85%95이 되고, 공백은 %20, &는 %26으로 인코딩됩니다. 본 도구는 JavaScript 표준 함수 encodeURI / encodeURIComponent를 양쪽 모두 제공해 URL 전체를 인코딩할 때와 쿼리 파라미터 값만 인코딩할 때를 정확히 구분해 사용할 수 있습니다. 모든 변환은 브라우저에서 수행되어 외부로 전송되지 않습니다.
encodeURI vs encodeURIComponent — 무엇을 써야 할까?
| 함수 | 인코딩 안 함 | 언제 쓰나 |
|---|---|---|
| encodeURI | : / ? # & = + 등 URL 구조 문자 | URL 전체 인코딩 |
| encodeURIComponent | A-Z a-z 0-9 - _ . ! ~ * ' ( ) | 쿼리 파라미터 값, 경로 일부 |
※ "https://example.com/검색?q=한글&cat=A"처럼 URL 전체는 encodeURI, 그 안의 "한글"이나 "A&B" 같은 값만은 encodeURIComponent로 처리.
자주 쓰이는 인코딩 결과
| 원본 | 인코딩 |
|---|---|
| 공백 | %20 |
| 한 | %ED%95%9C |
| 국 | %EA%B5%AD |
| ! | %21 |
| @ | %40 |
| # | %23 |
| & | %26 |
| = | %3D |
| + | %2B |
| / | %2F |
언제 URL 인코딩이 필요한가?
- • 검색 쿼리 — 네이버·구글 검색 URL의 query 값. 한글 검색어는 항상 인코딩.
- • REST API 요청 — Path parameter나 Query string에 한글·특수문자 포함 시 필수.
- • OAuth 콜백 URL — redirect_uri의 한글 도메인이나 파라미터 인코딩.
- • SMS·카카오톡 링크 — 메시지에 포함되는 짧은 URL의 파라미터 인코딩.
- • 파일 다운로드 링크 — 한글 파일명이 포함된 다운로드 URL.
- • 로그 분석 — 인코딩된 URL을 디코딩해 사용자 검색어·이동 경로 분석.
자주 묻는 질문 (FAQ)
Q. + 기호가 공백으로 변환되지 않아요
A. URL 인코딩 표준에서 공백은 %20입니다. + 기호를 공백으로 바꾸는 것은 application/x-www-form-urlencoded(폼 전송) 규칙으로, URL 표준과는 다릅니다. 폼 형식이 필요하면 인코딩 후 %20을 +로 추가 치환하세요.
Q. 이중 인코딩(double encoding)이란?
A. 이미 인코딩된 문자열을 한 번 더 인코딩하면 %가 %25로 변해 깨집니다. 예: 한 → %ED%95%9C → %25ED%2595%259C. 인코딩이 중첩되지 않도록 입력 단계에서 한 번만 적용하세요.
Q. 한국어 도메인(한글.한국)도 인코딩되나요?
A. 도메인은 별도의 Punycode 인코딩(xn--로 시작)을 사용합니다. URL 인코딩과는 다른 규칙이니 도메인은 그대로 두고 경로·쿼리만 인코딩하세요.
Q. 입력한 URL이 외부로 전송되나요?
A. 아니요. 모든 변환은 브라우저에서 수행되며 외부 서버로 전송되지 않습니다. 내부 시스템 URL이나 인증 토큰이 포함된 콜백 URL도 안전하게 디코딩할 수 있습니다.
Q. Base64 인코딩과는 뭐가 다른가요?
A. URL 인코딩은 안전하지 않은 문자만 %XX로 치환하는 방식이고, Base64는 모든 바이트를 64개 문자로 표현하는 방식입니다. URL 인코딩은 사람이 읽을 수 있고, Base64는 길이가 약 33% 늘어나지만 어떤 바이너리도 안전하게 표현 가능합니다.