URL 인코더 · 디코더

세 가지 인코딩 방식

URL 인코딩은 하나가 아닙니다. 쓰는 위치에 따라 세 가지가 있고, 잘못 고르면 값이 깨집니다.

값 하나를 감쌀 때 (encodeURIComponent)

쿼리 파라미터의 값 하나를 넣을 때 씁니다. /, ?, &, =, #까지 전부 인코딩합니다.

값 안에 &나 =가 들어 있어도 파라미터가 잘못 쪼개지지 않습니다. 파라미터 값에는 반드시 이 방식을 써야 합니다.

URL 전체를 넘길 때 (encodeURI)

주소 전체를 인코딩하되 구조 문자는 그대로 둡니다. 그래서 URL이 URL로서 유효하게 남습니다. 한글 경로가 포함된 주소를 통째로 인코딩할 때 씁니다.

폼 전송 (x-www-form-urlencoded)

HTML 폼이 GET으로 전송할 때 쓰는 방식입니다. 다른 방식과 딱 하나 다릅니다. 공백을 %20이 아니라 +로 바꿉니다.

공백이 %20이 되기도 +가 되기도 하는 이유

| 위치 | 공백 표현 | |---|---| | URL 경로 | %20 | | 일반 쿼리스트링 | %20 | | HTML 폼 전송 | + |

문제는 두 방식이 섞일 때입니다. +로 인코딩된 값을 decodeURIComponent로 풀면 +가 공백이 아니라 진짜 더하기 기호로 남습니다. 반대로 진짜 +가 들어 있는 값(예: 전화번호 +82-10-...)을 폼 방식으로 디코딩하면 공백이 되어 버립니다.

이 도구에서 방식을 바꿔 가며 결과를 비교해 보면 차이가 바로 보입니다.

한글 주소가 길어지는 이유

URL은 ASCII만 담을 수 있습니다. 그래서 한글은 먼저 UTF-8 바이트로 바뀌고, 각 바이트가 %XX 형태로 표현됩니다.

한글 한 글자는 UTF-8에서 3바이트이므로 한 → %ED%95%9C으로 9자가 됩니다. 열 글자짜리 한글 검색어는 90자로 불어납니다.

브라우저 주소창이 한글로 보여 주는 것은 사용자 편의를 위한 표시일 뿐이고, 실제 전송되는 값은 인코딩된 형태입니다. 주소를 복사해 다른 곳에 붙여넣으면 %ED%95%9C...가 나오는 이유입니다.

인코딩을 두 번 하면

가장 자주 겪는 버그입니다.

• 원본: 한글
• 한 번 인코딩: %ED%95%9C%EA%B8%80
• 두 번 인코딩: %25ED%2595%259C...

%가 다시 %25로 인코딩되면서 값이 망가집니다. 서버는 이를 디코딩해도 %ED%95%9C이라는 문자열을 얻을 뿐 한글로 돌아가지 않습니다.

이미 인코딩된 값을 다시 인코딩하지 않도록, 어느 단계에서 인코딩하는지 명확히 정해 두어야 합니다. 대개 URL을 조립하는 마지막 지점에서 한 번만 합니다.

인코딩되지 않는 문자

다음 문자들은 URL에서 안전하다고 규정되어 인코딩되지 않습니다.

A-Z a-z 0-9 - _ . ~

encodeURIComponent는 여기에 더해 !, ', (, ), *도 남겨 둡니다. 이 문자들이 문제가 되는 시스템이 있다면 직접 치환해야 합니다.

쿼리스트링을 직접 조립하지 마세요

문자열을 이어 붙여 URL을 만들면 인코딩을 빠뜨리기 쉽습니다. 대신 표준 API를 쓰세요.

const url = new URL("https://so-yi.com/search");
url.searchParams.set("q", "연봉 실수령액 & 세금");
// 알아서 인코딩됩니다

URLSearchParams는 값에 어떤 문자가 들어 있든 안전하게 처리합니다. 위 도구의 "URL 구성 요소" 표도 같은 API로 파싱한 결과입니다.

함께 확인하면 좋은 것

바이너리를 텍스트로 옮겨야 한다면 Base64 인코더를, 패턴으로 URL을 검사하려면 정규식 테스터를 이용하세요.