URL 인코딩이란? URL 인코더/디코더 사용법 가이드 2026

URL에 한글 넣었더니 %EC%95%88... 이런 괴상한 문자열로 바뀐 경험 있죠? 이게 URL 인코딩이에요. URL에는 영어, 숫자, 몇 개의 특수문자만 허용되거든요. 한글이나 공백 같은 '안전하지 않은' 문자는 %XX 형태로 변환해야 브라우저가 이해해요. API 개발할 때 이거 모르면 한글 파라미터 때문에 반나절 삽질하게 됩니다.

URL 인코딩이란?

URL 인코딩은 URL에서 허용되지 않는 문자를 퍼센트 인코딩 형식으로 변환합니다. 퍼센트 기호(%)와 해당 문자의 ASCII/UTF-8 바이트 값을 나타내는 두 자리 16진수로 구성됩니다. 예를 들어, 공백은 %20이 되고, 한글 '가'는 %EA%B0%80(3바이트 UTF-8)이 됩니다.

• 공백 → %20 (폼 데이터에서는 +)
• & → %26 (앰퍼샌드, 쿼리 구분자)
• = → %3D (등호, key=value 쌍에 사용)
• / → %2F (슬래시, URL 경로 구분자)
• ? → %3F (물음표, 쿼리 스트링 구분자)
• # → %23 (해시, 프래그먼트 식별자)
• 비ASCII 문자(한글, 중국어 등) → UTF-8 바이트당 여러 %XX 시퀀스

왜 URL 인코딩이 필요한가?

RFC 3986은 URI에서 허용되는 문자를 정의합니다. 영문자(A-Z, a-z), 숫자(0-9), 그리고 소수의 특수문자(-, _, ., ~)만 허용됩니다. 공백, 한글 등 비영문 문자, 그리고 예약 문자를 다른 용도로 사용할 때는 반드시 퍼센트 인코딩해야 합니다.

• 브라우저 호환성: 인코딩되지 않은 문자를 브라우저마다 다르게 처리할 수 있음
• 서버 처리: 웹 서버는 ?, &, = 같은 예약 문자를 기준으로 URL을 파싱
• 데이터 무결성: 인코딩 없이 특수문자를 쿼리 값에 넣으면 URL 구조가 깨질 수 있음
• 국제화: 한글, 일본어, 아랍어 등 비ASCII 문자는 안정적인 전송을 위해 인코딩 필수

encodeURI vs encodeURIComponent 차이

JavaScript는 URL 인코딩을 위한 두 가지 내장 함수를 제공합니다. 잘못된 함수를 선택하는 것이 개발자가 가장 흔히 하는 실수입니다:

// encodeURI — 전체 URL을 인코딩할 때
// 인코딩하지 않는 문자: A-Z a-z 0-9 ; , / ? : @ & = + $ - _ . ! ~ * ' ( ) #
encodeURI('https://example.com/path?q=안녕 세계&lang=ko')
// → 'https://example.com/path?q=%EC%95%88%EB%85%95%20%EC%84%B8%EA%B3%84&lang=ko'

// encodeURIComponent — 쿼리 값을 인코딩할 때
// 인코딩하지 않는 문자: A-Z a-z 0-9 - _ . ! ~ * ' ( )
encodeURIComponent('안녕 세계&lang=ko')
// → '%EC%95%88%EB%85%95%20%EC%84%B8%EA%B3%84%26lang%3Dko'

URL 파싱: URL 구조 분석

URL 구조를 이해하면 무엇을 어디서 인코딩해야 하는지 알 수 있습니다. URL은 여러 구성 요소로 이루어져 있습니다:

https://example.com:8080/path/to/page?name=%ED%99%8D%EA%B8%B8%EB%8F%99&city=Seoul#section1
|____| |_____________||__||____________||________________________________________||________|
프로토콜   호스트       포트    경로                    검색(쿼리)                    해시

• 프로토콜(스킴): http, https, ftp — 인코딩 불필요
• 호스트: 도메인명 또는 IP — 인코딩이 거의 불필요 (국제 도메인은 punycode 처리)
• 포트: 숫자 — 인코딩 불필요
• 경로: 경로 세그먼트 — 특수문자가 포함되면 개별 세그먼트를 인코딩
• 쿼리 스트링: &로 구분된 key=value 쌍 — 키와 값 모두 encodeURIComponent로 인코딩
• 프래그먼트(해시): # 뒤의 부분 — 특수문자가 포함되면 인코딩

흔한 URL 인코딩 실수

• 이중 인코딩: 이미 인코딩된 문자열을 다시 인코딩 (예: %20이 %2520이 됨). 인코딩 전에 입력이 이미 인코딩되었는지 확인하세요.
• 쿼리 값에 encodeURI 사용: &와 =를 인코딩하지 않아 쿼리 스트링 구조가 깨집니다.
• 인코딩 생략: 사용자 입력을 인코딩 없이 URL에 넣으면 링크가 깨지거나 보안 문제(XSS, 인젝션)가 발생합니다.
• 전체 URL에 encodeURIComponent 사용: //, /, ? 등이 인코딩되어 URL 자체가 깨집니다.
• 공백 인코딩 혼동: 폼은 공백에 +를 사용하고(application/x-www-form-urlencoded), URL은 %20을 사용합니다. 어떤 컨텍스트인지 확인하세요.