URL 인코딩 / 디코딩 — 퍼센트 인코딩과 URL 파서

컴포넌트, 전체 URL, 폼 모드로 URL용 텍스트를 퍼센트 인코딩하거나 디코딩하고, URL의 쿼리 매개변수를 표에서 편집하세요.

모드 줄마다 따로

encodeURIComponent: 쿼리 값 하나나 경로 세그먼트 하나에 사용합니다. A–Z a–z 0–9 - _ . ! ~ * ' ( )를 제외한 모든 문자를 이스케이프합니다.

인코딩할 텍스트

인코딩 결과

name%3DZo%C3%AB%20%26%20Tom%20%2F%20caf%C3%A9%3Fid%3D42%23top

URL 파서와 쿼리 문자열 편집기

URL

프로토콜	https:
호스트	shop.example.com
포트	8443
경로	/search/trail%20shoes
쿼리	?q=trail+running&size=10&color=blue%20%26%20green&utm_source=newsletter
프래그먼트	#reviews
오리진	https://shop.example.com:8443

쿼리 매개변수(0개) — 디코딩됨, 자유롭게 편집하세요

공백을 +로 인코딩

재구성된 URL

https://shop.example.com:8443/search/trail%20shoes#reviews

모든 작업이 브라우저에서 실행됩니다. 입력한 내용은 전송되거나 저장되지 않습니다. 모든 무료 도구 보기.

문제를 발견하셨거나 개선할 점이 있나요? 모든 메시지를 읽고 빠르게 고칩니다.

이 URL 인코더·디코더는 공백, 앰퍼샌드, 악센트 문자, 이모지가 URL 안에서 안전하게 전달되도록 하는 %20 형식의 퍼센트 인코딩으로 텍스트를 변환하고 되돌립니다. 개발자들이 실제로 헷갈리는 세 가지 인코딩을 제공합니다. 쿼리 값 하나나 경로 세그먼트용 컴포넌트 모드(encodeURIComponent), URL 자체의 구두점은 그대로 두는 전체 URL 모드(encodeURI), 그리고 HTML 폼과 URLSearchParams가 보내는 방식으로 공백을 +로 쓰는 폼 모드입니다.

디코딩은 의도적으로 엄격합니다. 브라우저의 decodeURIComponent는 그냥 "URI malformed" 오류만 내지만, 이 도구는 어느 % 시퀀스가 어디서 깨졌는지, 바이트가 유효한 UTF-8이 아닌지(앞 단계에서 Latin-1을 썼다는 흔한 신호)를 알려 줍니다. 인코더 아래의 URL 파서는 URL을 구성 요소로 나누고 쿼리 매개변수를 편집 가능한 표로 보여 주며, 값을 바꾸면 URL을 다시 만들어 줍니다.

사용 방법

인코딩 또는 디코딩을 고른 다음 모드를 고르세요. URL에 넣을 값은 컴포넌트, 주소 전체는 전체 URL, application/x-www-form-urlencoded 데이터는 폼입니다.
텍스트를 입력하거나 붙여 넣으세요. 입력하는 대로 결과가 업데이트되며, 목록이라면 “줄마다 따로”를 체크하세요.
디코딩이 실패하면 메시지를 읽으세요. 위치와 깨진 시퀀스를 알려 줍니다.
URL을 살펴보거나 편집하려면 파서에 붙여 넣고 쿼리 매개변수를 바꾸거나 추가·제거한 뒤 다시 만들어진 URL을 복사하세요.

자주 묻는 질문

encodeURI와 encodeURIComponent의 차이는 무엇인가요?

encodeURIComponent는 문자, 숫자, - _ . ! ~ * ' ( )를 제외한 모든 것을 이스케이프하므로, &나 =가 들어갈 수 있는 쿼리 값처럼 URL의 한 부분에 안전합니다. encodeURI는 URL 전체를 받는다고 가정해 URL 구조를 이루는 문자(: / ? # @ & = + $ , ;)는 그대로 둡니다. 값에 encodeURI를 쓰는 것은 고전적인 버그입니다. 값 안의 &가 매개변수를 둘로 나눠 버립니다.

공백은 %20인가요, +인가요?

둘 다 쓰이는 곳이 다를 뿐 맞습니다. 폼 제출의 쿼리 문자열(application/x-www-form-urlencoded)에서는 공백이 +이고, 실제 더하기 기호는 %2B로 써야 합니다. 경로와 직접 만든 대부분의 쿼리 문자열을 포함한 그 밖의 모든 곳에서는 공백이 %20이고 +는 실제 더하기 기호입니다. 서버에 공백 자리에 더하기 기호가 보이거나 그 반대라면, 양쪽이 어떤 규칙을 적용할지 서로 다르게 알고 있는 것입니다.

"URI malformed" 오류가 나는 이유는 무엇인가요?

% 기호 뒤에 16진수 두 자리가 오지 않았거나(예: "100%", "%zz"), 바이트가 유효하지 않은 UTF-8인 경우입니다. 예를 들어 %E9 하나만 있으면 Latin-1에서는 é이지만 UTF-8에서는 아닙니다. 실제 퍼센트 기호는 %25로 써야 합니다. 이 도구는 정확한 위치를 알려 주므로 어느 쪽인지 알 수 있습니다.

어떤 문자를 URL 인코딩해야 하나요?

RFC 3986은 문자, 숫자, - . _ ~만 어디서나 인코딩 없이 쓸 수 있게 합니다. 예약 문자(: / ? # [ ] @ ! $ & ' ( ) * + , ; =)는 구조가 아니라 값 안에 나올 때 인코딩해야 합니다. 공백, 따옴표, < >, 비ASCII 문자, 이모지를 포함한 나머지는 항상 그 문자의 UTF-8 바이트로 인코딩해야 합니다.

URL 인코딩은 암호화의 일종인가요?

아니요. 퍼센트 인코딩은 키가 없는 되돌릴 수 있는 이스케이프 방식이라 누구나 즉시 디코딩할 수 있습니다. URL에서 토큰이나 개인 정보를 숨기는 데 절대 의존하지 마세요. URL은 브라우저 기록, 서버 로그, Referer 헤더에 남으므로 비밀 정보는 아예 쿼리 문자열에 넣지 말아야 합니다.

인코딩 참조: 모드별로 그대로 두는 문자

• 컴포넌트(encodeURIComponent): A–Z a–z 0–9 - _ . ! ~ * ' ( )를 그대로 둡니다. 쿼리 값, 경로 세그먼트, 문자열 연결로 만드는 모든 것에 쓰세요.

• 전체 URL(encodeURI): 추가로 ; , / ? : @ & = + $ #를 그대로 둡니다. 공백이나 비ASCII 문자가 들어간 완전한 URL을 정리할 때만 쓰세요.

• 폼(application/x-www-form-urlencoded): A–Z a–z 0–9 * - . _를 그대로 두고 공백을 +로 바꿉니다. URLSearchParams.toString()과 HTML 폼이 만드는 방식입니다.

• RFC 3986 비예약 문자 집합: A–Z a–z 0–9 - . _ ~. 가장 엄격한 해석으로, ! ' ( ) *까지 인코딩해도 항상 안전합니다.

비ASCII 문자는 항상 UTF-8 바이트로 인코딩됩니다. é는 %C3%A9, 이모지 🌲는 4바이트인 %F0%9F%8C%B2입니다.

이중 인코딩과 그 밖의 흔한 버그

이중 인코딩은 이미 인코딩된 문자열을 다시 인코딩할 때 생깁니다. % 자체가 %25로 이스케이프되므로 %20이 %2520이 됩니다. URL에서 %25 뒤에 16진수 두 자리가 보이면 무언가가 두 번 인코딩한 것입니다. 한 번 디코딩하고 결과에 여전히 % 시퀀스가 있는지 확인하세요.

반대 실수는 인코딩 없이 문자열 연결로 URL을 만드는 것입니다. 그러면 "fish & chips" 검색이 q=fish와 " chips"라는 엉뚱한 매개변수로 전송됩니다. URLSearchParams로 쿼리 문자열을 만들거나 각 값을 encodeURIComponent로 인코딩하면 두 문제를 모두 막을 수 있습니다.

마지막으로, 사용자 입력을 디코딩한 뒤 HTML에 넣는 것이 반사형 크로스 사이트 스크립팅이 시작되는 방식입니다. 표시용으로 디코딩할 때는 반드시 HTML 이스케이프를 거치세요. HTML 엔티티 인코더가 그 단계를 처리합니다.