§

디코딩할 텍스트를 입력하세요:

디코딩하려는 URL 인코딩 텍스트를 입력하세요. 이 도구는 퍼센트 인코딩된 문자를 원래 형태로 변환합니다.
§

Output

decoded

GA4 UTM 파라미터의 한글 캠페인 이름, 쿠팡·11번가·G마켓 트래픽 로그에 박힌 %EC%83%81%ED%92%88 같은 시퀀스, 카카오·네이버 OAuth state 토큰, 네이버 검색광고 리포트의 인코딩된 키워드 — KISA가 정의한 한국형 WAF 룰셋이 남긴 퍼센트 이스케이프나 정부24 리디렉션 URL까지, 외부 서버로 전송하지 않고 사람이 읽을 수 있는 한글로 즉시 복원합니다.

// 관련 도구

./url-encoder
URL 인코더
URL에서 안전하게 전송할 수 있도록 문자열을 퍼센트 인코딩합니다.
→
./url-parser
URL 파서
URL을 구성 요소로 분해하고 쿼리 문자열을 디코딩하여 재구성합니다.
→
./base64-encoder
Base64 인코더
텍스트와 파일을 Base64 형식으로 인코딩합니다.
→
./
전체 도구
Ultim8Soft 온라인 도구 전체 모음을 살펴보세요.
→

고급 옵션

+ 를 공백으로 변환

활성화하면 + 문자가 공백으로 변환됩니다. 쿼리 매개변수를 디코딩할 때 유용합니다.

실시간 모드

활성화하면 입력하는 동안 텍스트가 자동으로 디코딩됩니다.

이 옵션들은 URL에서 인코딩된 문자의 디코딩 방식을 제어하는 데 도움이 됩니다.

URL 디코딩이란 무엇인가요?

URL 디코딩은 퍼센트 인코딩의 역과정입니다. 인코딩된 URL의 %XX 이스케이프 시퀀스를 읽어 원래 문자로 되돌립니다. 이를 통해 브라우저, API 또는 로그 줄이 인코딩된 형태로 전달한 URL에서 읽을 수 있는 쿼리 문자열, 폼 값 또는 경로 세그먼트를 복원할 수 있습니다.

URL 디코딩은 어떻게 작동하나요?

URL 디코딩은 퍼센트 인코딩된 시퀀스를 원래 문자로 다시 변환하는 특정 프로세스를 따릅니다:

  1. 입력 문자열에서 퍼센트 인코딩된 이스케이프 시퀀스(%XX)를 검색합니다
  2. 각 %XX를 두 개의 16진수 숫자에서 원래 바이트 값으로 다시 변환합니다
  3. 연속된 디코딩 바이트를 UTF-8 문자로 재조합합니다(멀티바이트 시퀀스가 하나의 문자가 됨)
  4. 쿼리 문자열 컨텍스트에서 +는 공백으로 디코딩되며(application/x-www-form-urlencoded), %2B는 리터럴 +로 남습니다
  5. 비예약 문자와 이미 디코딩된 텍스트는 변경 없이 그대로 전달됩니다

URL 디코더를 사용하는 이유는 무엇인가요?

  • 읽기 쉬운 출력: %20, %40, %3D를 공백, @, =으로 되돌려 URL이 실제로 무엇을 담고 있는지 읽을 수 있게 합니다
  • 국제 텍스트: UTF-8 바이트 시퀀스에서 악센트 문자와 비 ASCII 문자를 재조합하여 %C3%A9가 다시 é로 읽히게 합니다
  • 디버깅: 쿼리 문자열, OAuth 리디렉션 또는 웹훅 페이로드 안의 실제 값을 실행 전에 검사합니다
  • 표준 준수: RFC 3986에 따라 디코딩하며, 브라우저와 서버가 사용하는 것과 동일한 규칙으로 그것들이 보는 것과 동일한 결과를 확인합니다

URL 디코딩의 일반적인 활용 사례는 무엇인가요?

URL 디코딩은 많은 웹 개발 시나리오에서 필수적입니다:

  • 폼 제출: application/x-www-form-urlencoded GET 및 POST 데이터에서 원래 필드 값을 다시 읽어옵니다
  • API 개발: API 엔드포인트에 도착하는 퍼센트 인코딩된 경로 및 쿼리 매개변수를 언패킹합니다
  • 파일 시스템: URL 내에서 전달하기 위해 퍼센트 인코딩된 파일 경로와 이름을 복원합니다
  • 링크 디버깅: 공유되거나 기록된 URL을 디코딩하여 담긴 특수 문자와 국제 텍스트를 확인합니다

URL 디코딩 예시는 어떻게 생겼나요?

다음은 URL 디코딩의 일반적인 예시입니다: %20(또는 +)은 공백이 되고, %40은 @, %23은 #, %26은 &, %3D는 =가 됩니다. %C3%A9 같은 UTF-8 시퀀스는 국제 문자 é가 됩니다.

퍼센트 인코딩이란 무엇인가요?

퍼센트 인코딩은 RFC 3986 §2.1에서 URI 내부에 안전하지 않거나 예약된 문자를 표현하기 위해 정의한 메커니즘입니다. 규칙은 기계적입니다: 그대로 등장할 수 없는 모든 바이트는 퍼센트 기호 뒤에 두 개의 16진수 — %XX 형태 — 로 표기되며, XX는 해당 바이트 값입니다. é 같은 비 ASCII 문자는 먼저 UTF-8 바이트 시퀀스로 인코딩된 다음 각 바이트가 개별적으로 퍼센트 인코딩됩니다. 개발자는 이를 거의 매일 만납니다: 쿼리 문자열, 폼 제출, OAuth 콜백 URL, REST API 경로 매개변수, 그리고 URL이 문장 부호·공백·비예약 집합 A–Z a–z 0–9 - _ . ~ 밖의 문자를 운반해야 하는 모든 곳에서.

%C3%A9를 é로 디코딩하는 과정은 실제로 어떻게 동작하나요?

인코딩된 쿼리 문자열 ?q=caf%C3%A9&lang=fr을 살펴봅시다. 디코딩하면 ?q=café&lang=fr이 나옵니다. 아래는 바이트 단위 설명입니다:

  • 입력: ?q=caf%C3%A9&lang=fr
  • 출력: ?q=café&lang=fr
  1. %C3 → 바이트 0xC3(이진수 11000011) — 2바이트 UTF-8 시퀀스의 선두 바이트.
  2. %A9 → 바이트 0xA9(이진수 10101001) — 후속 바이트. 둘을 합친 C3 A9는 U+00E9의 UTF-8 인코딩, 즉 é입니다.
  3. ?, =, & 문자는 구조적이기 때문에 손대지 않습니다 — 이들은 쿼리와 그 키/값 쌍을 구분합니다. 리터럴 caf 역시 그대로 통과하는데, 소문자 ASCII 글자는 비예약 집합에 속하기 때문입니다.

decodeURIComponent와 decodeURI의 차이는 무엇인가요?

JavaScript는 두 개의 내장 디코더를 제공하며, 둘을 혼동하는 것은 URL 처리에서 가장 흔한 버그 중 하나입니다:

  • decodeURIComponent(str)는 &, =, ?, /, #처럼 예약된 문자까지 포함해 모든 퍼센트 인코딩 시퀀스를 디코딩합니다. 개별 쿼리 문자열 값이나 경로 세그먼트에 사용하고, 전체 URL에는 절대 사용하지 마세요.
  • decodeURI(str)는 의도적으로 보수적입니다: 예약 문자는 건너뜁니다. %26을 넘기면 &가 아니라 문자 그대로의 %26이 반환됩니다. 구조를 왕복하더라도 보존하고 싶은 전체 URI를 위해 설계된 함수입니다.

경험 법칙: 문자열이 URL의 일부(단일 매개변수, 프래그먼트, 인코딩된 파일명)라면 decodeURIComponent를 사용하세요. 이 도구는 decodeURIComponent처럼 동작합니다 — 입력 안의 모든 %XX 시퀀스가 예약 문자를 포함해 디코딩됩니다.

URL을 디코딩한다는 것은 그 안에 무엇이 담겨 있는지 읽는 것입니다. 위에 인코딩된 문자열을 붙여넣으면 모든 %XX 시퀀스가 브라우저에서 곧바로 해당 문자로 변환됩니다. 서버에 아무것도 보내지 않고도 쿼리 매개변수를 디버깅하거나, OAuth 리디렉션을 확인하거나, 악센트가 있는 파일 이름을 복원할 수 있습니다.