URL 인코더·디코더

URL 인코딩은 글자를 %와 16진수 두 자리로 바꿉니다

URL에는 영문·숫자와 몇 가지 기호만 그대로 쓸 수 있습니다. 그 밖의 글자는 먼저 바이트로 바꾼 뒤 바이트마다 %와 16진수 두 자리로 적는데, 이것을 퍼센트 인코딩 또는 URL 인코딩이라고 합니다. 한글은 UTF-8로 한 글자가 3바이트라서 '한'은 %ED%95%9C 9자가 되고, 공백은 %20이 됩니다(폼 전송에서는 +). URL 디코딩은 반대로 %XX를 바이트로 되돌린 뒤 글자로 읽는 일입니다.

같은 글이라도 주소의 어느 자리에 넣느냐에 따라 결과가 달라집니다. 검색어처럼 값 하나로 넣을 글은 &·=·/·?까지 바꿔야 하고, 이미 주소 꼴인 글은 그 구분 기호를 그대로 둬야 주소가 열립니다. 이 도구는 두 칸 가운데 고친 칸을 기준으로 바로 바꾸고, 주소를 부분별로 나눠 풀며, EUC-KR로 만든 옛 주소와 두 번 인코딩된 값도 가려냅니다. URL 인코딩은 암호화가 아니어서 누구나 원래 글로 되돌릴 수 있습니다.

URL을 인코딩하거나 풀어야 하는 상황

• 붙여 넣은 주소가 %로 길게 보일 때: 메신저나 문서에 붙인 주소가 %EC%84%9C%EC%9A%B8…처럼 보이면 어떤 페이지인지 알기 어렵습니다. 인코딩 칸에 붙이면 검색어와 경로가 한글로 보입니다.
• 한글 검색어·상품명을 링크에 넣을 때: 'A&B'나 'C++'를 그대로 붙이면 & 뒤가 다른 항목으로, +가 공백으로 읽힙니다. 값 하나 규칙으로 바꿔 붙여야 그대로 전달됩니다.
• 로그인·결제 뒤 돌아올 주소를 값으로 넣을 때: redirect_uri나 returnUrl에 넣는 주소는 안쪽 주소를 통째로 인코딩해야 바깥 주소와 섞이지 않습니다.
• API 서명을 만들 때: OAuth 1.0 서명과 AWS 서명 버전 4는 RFC 3986 비예약 문자만 그대로 두고 공백을 %20으로 적어야 서명이 맞습니다. 한 글자만 달라도 인증이 실패합니다.
• 접속 기록·분석 도구의 주소를 읽을 때: 서버 로그와 유입 경로에는 주소가 인코딩된 채 남습니다. 어떤 검색어로 들어왔는지 보려면 풀어야 합니다.
• 옛 게시판·쇼핑몰 주소를 읽을 때: EUC-KR로 만든 사이트는 '한글'을 %C7%D1%B1%DB로 적어서 UTF-8 디코더로는 깨집니다.

쓰는 법

1. 풀기(디코딩): 오른쪽 URL 인코딩 칸에 %가 섞인 주소나 값을 붙여 넣습니다. 붙여 넣은 모양을 보고 규칙을 고르고(주소면 주소 전체, + 공백이 보이면 폼 +), 왼쪽 원문 칸에 풀린 글이 나옵니다.
2. 인코딩: 왼쪽 원문 칸에 글을 넣고 넣을 자리에 맞는 규칙을 고릅니다. 검색어·파일 이름·이동 주소처럼 값 하나면 '값 하나', 주소 전체면 '주소 전체', HTML 폼과 같은 결과가 필요하면 '폼 +', 서명용이면 '엄격'입니다.
3. 주소 해부 보기: 칸의 글이 주소나 쿼리 문자열이면 스킴·호스트·경로·쿼리 값·조각을 나눠 각각 풀어 보여 줍니다. 값 속에 다른 주소가 있으면 '이 주소 풀기'로 그 주소를 다시 펼칩니다. 여러 줄이면 커서가 있는 줄을 해부합니다.
4. 글자 인코딩: 기본값은 자동 판별입니다. UTF-8로 읽히지 않으면 EUC-KR·Shift_JIS·Windows-1252 가운데 맞는 쪽으로 읽고 옆에 표시합니다. 옛 사이트에 맞춰 인코딩하려면 직접 고릅니다.
5. 기호 지도와 함수 결과: 기호를 누르면 네 규칙에서 어떻게 바뀌는지와 그 까닭이 나옵니다. 언어·함수별 결과는 원문 칸의 글을 JavaScript·PHP·Python 함수로 바꾼 결과이며, 지금 규칙과 다른 글자를 표시합니다. 줄을 누르면 그 결과가 복사됩니다.

네 가지 규칙, 무엇을 그대로 두나

규칙마다 영문·숫자 말고 그대로 두는 기호가 다릅니다. 다른 도구나 코드와 결과가 다르다면 대개 이 차이 때문입니다.

엄격 규칙의 네 기호는 RFC 3986이 비예약 문자로 정한 것이라, 이 문자를 인코딩하든 안 하든 같은 주소로 봅니다. 값 하나 규칙이 ! ' ( ) *까지 두는 것은 JavaScript가 옛 규격 RFC 2396의 비예약 문자를 따랐기 때문이며, URL 표준도 이 집합을 component 집합으로 따로 정해 두었습니다.

폼 + 규칙은 URLSearchParams와 같습니다. 브라우저가 실제로 HTML 폼을 보낼 때는 여러 줄 입력칸의 줄바꿈을 %0D%0A로 바꾸지만, 이 도구와 URLSearchParams는 %0A로 둡니다(Chromium 151 실측).

기호별로 보면

자주 헷갈리는 기호가 규칙마다 어떻게 바뀌는지 모았습니다. 주소 전체 칸은 http·https 주소의 쿼리 자리 기준입니다. 도구 위의 기호 지도에서는 35개 기호를 모두 눌러 볼 수 있습니다.

주소 전체 규칙이 %를 그대로 두는 까닭은 이미 인코딩된 %XX를 지키기 위해서입니다. 대신 글자 그대로의 %가 들어 있으면 그 뒤 두 글자가 16진수인지 따로 확인해야 하므로, 도구가 그런 %의 개수를 알려 줍니다. PHP urlencode()는 폼 규칙과 비슷하지만 *도 %2A로 바꾸고, Python quote()는 엄격 규칙에 /만 더 둡니다.

%20과 +, 공백은 어떻게 읽히나

공백을 +로 적는 것은 HTML 폼 전송(application/x-www-form-urlencoded)의 규칙입니다. 경로에서 +는 그냥 더하기 기호이고, 쿼리에서도 받는 쪽이 어떤 함수로 푸느냐에 따라 공백이 되기도 하고 더하기로 남기도 합니다. 그래서 진짜 더하기는 %2B로, 공백은 %20으로 적으면 어느 쪽에서도 같은 뜻으로 읽힙니다.

이 도구는 폼 + 규칙에서만 +를 공백으로 읽습니다. 값 하나·엄격 규칙으로 풀었는데 +가 남아 있으면 상태 줄에 '폼 + 규칙으로 읽기' 단추가 나옵니다. 주소 전체 규칙은 구조를 지키려고 +를 그대로 두고, 아래 주소 해부에서 쿼리 값만 폼 규칙으로 풀어 보여 줍니다.

주소 전체를 인코딩할 때, encodeURI와 브라우저의 차이

주소 전체를 바꿀 때 흔히 쓰는 encodeURI()는 구분 기호를 두지만 %도 바꾸고 도메인을 따로 다루지 않습니다. 브라우저 주소창은 URL 표준에 따라 경로·쿼리·조각마다 다른 집합을 쓰고, 이미 있는 %XX는 두며, 한글 도메인은 퓨니코드로 바꿉니다. 이 도구의 주소 전체 규칙은 브라우저 쪽을 따릅니다.

마지막 줄처럼 값 속에 주소가 그대로 들어 있으면 어느 방식도 고쳐 주지 못합니다. 바깥 주소는 y=2를 자기 항목으로 읽기 때문입니다. 안쪽 주소를 값 하나 규칙으로 따로 바꿔 next=https%3A%2F%2Fb.com%2F%3Fx%3D1%26y%3D2처럼 붙여야 합니다. 도구는 주소 전체 규칙에서 이런 값을 찾으면 상태 줄에 알립니다.

두 번 인코딩과 한 겹 풀기

이미 인코딩된 글을 다시 인코딩하면 %가 %25로 바뀝니다. 그래서 %20은 %2520이 되고, 한 번 풀면 %20, 다시 풀어야 공백이 됩니다. 프레임워크나 HTTP 라이브러리가 값을 알아서 인코딩하는데 코드에서 한 번 더 바꿨을 때 흔히 생깁니다. RFC 3986 2.4절도 같은 글을 두 번 인코딩하거나 두 번 풀지 말라고 정합니다.

인코딩 칸의 글에 %25 다음 16진수 두 자리가 보이면 도구가 두 번 인코딩으로 짐작하고 '한 겹 더 풀기' 단추를 보여 줍니다. 이 단추는 %25XX만 %XX로 바꾸므로, 주소의 다른 구분 기호는 건드리지 않습니다. 다만 원래 글에 '%20'이라는 글자 자체가 들어 있었다면 한 겹 더 푸는 것이 오히려 글을 바꾸니 출처를 확인합니다.

EUC-KR로 인코딩된 옛 주소

요즘 주소는 UTF-8이 기본이지만(RFC 3986 2.5절), 오래된 한국 사이트는 페이지를 EUC-KR(실제로는 확장판 CP949)로 만들어 폼으로 보낸 검색어도 그 바이트로 인코딩했습니다. 한글 한 글자가 2바이트라 '한'은 %C7%D1입니다. URL 표준도 http·https 주소의 쿼리는 페이지의 글자 인코딩으로 바꾸고 경로는 언제나 UTF-8로 바꾸도록 정해 두었습니다.

EUC-KR 값을 UTF-8로 풀면 바이트가 맞지 않아 �가 나옵니다. 이 도구의 자동 판별은 먼저 UTF-8로 읽어 보고, 실패하면 EUC-KR·Shift_JIS·Windows-1252로 읽은 결과 가운데 흔한 글자가 많은 쪽을 고릅니다. 반대로 옛 사이트에 넣을 값을 만들 때는 글자 인코딩을 EUC-KR로 고르면 됩니다. EUC-KR에 없는 글자(이모지 등)는 브라우저 폼처럼 &#번호;를 인코딩한 %26%23번호%3B로 적습니다.

한글 도메인은 퓨니코드로 바뀝니다

도메인(호스트)에는 퍼센트 인코딩을 쓰지 않습니다. 한글 도메인은 국제화 도메인 규칙(IDNA)에 따라 xn--으로 시작하는 ASCII 이름(퓨니코드, RFC 3492)으로 바뀝니다. 주소 전체 규칙은 호스트만 이렇게 바꾸고 경로·쿼리의 한글은 %XX로 바꾸며, 풀 때는 xn-- 이름을 다시 한글로 보여 줍니다.

코드로 할 때

// JavaScript
encodeURIComponent('한글 문서 & C++');         // %ED%95%9C%EA%B8%80%20%EB%AC%B8%EC%84%9C%20%26%20C%2B%2B
decodeURIComponent('%ED%95%9C%EA%B8%80');       // 한글 (잘못된 %가 있으면 URIError)
new URLSearchParams({ q: '서울 맛집' }).toString(); // q=%EC%84%9C%EC%9A%B8+%EB%A7%9B%EC%A7%91
new URL('https://한글.한국/소개').href;            // https://xn--bj0bj06e.xn--3e0b707e/%EC%86%8C%EA%B0%9C

# Python
from urllib.parse import quote, quote_plus, unquote, urlencode
quote('한글 문서', safe='')                       # %ED%95%9C%EA%B8%80%20%EB%AC%B8%EC%84%9C
quote_plus('한글 문서')                           # %ED%95%9C%EA%B8%80+%EB%AC%B8%EC%84%9C
unquote('%C7%D1%B1%DB', encoding='cp949')        # 한글
urlencode({'q': '서울 맛집', 'page': 2})          # q=%EC%84%9C%EC%9A%B8+%EB%A7%9B%EC%A7%91&page=2

// PHP
rawurlencode('한글 문서');   // %ED%95%9C%EA%B8%80%20%EB%AC%B8%EC%84%9C
urlencode('한글 문서');      // %ED%95%9C%EA%B8%80+%EB%AC%B8%EC%84%9C
http_build_query(['q' => '서울 맛집', 'page' => 2]);

// Java
URLEncoder.encode("한글 문서", StandardCharsets.UTF_8);  // %ED%95%9C%EA%B8%80+%EB%AC%B8%EC%84%9C
URLDecoder.decode("%ED%95%9C+%EA%B8%80", StandardCharsets.UTF_8); // 한 글

폼 규칙 함수(URLSearchParams, Python quote_plus(), PHP urlencode(), Java URLEncoder)는 공백을 +로 적으므로, 경로에 넣을 값이나 서명용 값에는 %20을 내는 함수를 씁니다.

자주 틀리는 경우

• 주소 전체를 값 하나 규칙으로 바꾼 경우: https%3A%2F%2F…가 되어 링크로 열리지 않습니다. 주소 자체를 고칠 때는 주소 전체 규칙을, 다른 주소의 값으로 넣을 때만 값 하나 규칙을 씁니다.
• 값 속 &·#를 그대로 둔 경우: 'A&B'는 A만 전달되고 #뒤는 서버에 가지 않습니다. 값 하나 규칙으로 A%26B, %23을 만듭니다.
• C++가 'C' 뒤 공백 둘로 바뀐 경우: 폼 규칙으로 푸는 곳에 +를 그대로 넣었기 때문입니다. C%2B%2B로 적습니다.
• %2520처럼 두 번 인코딩한 경우: 라이브러리가 이미 인코딩하는 값을 직접 한 번 더 바꾼 경우가 많습니다. 어느 단계에서 인코딩하는지 한 곳으로 정합니다.
• EUC-KR 값을 UTF-8로 푼 경우: 글자가 깨지거나 �가 나옵니다. 글자 인코딩을 EUC-KR로 바꿔 풉니다.
• decodeURIComponent가 멈춘 경우: '100%'처럼 % 뒤에 16진수 두 자리가 없으면 URIError로 멈춥니다. 이 도구는 그런 %를 그대로 두고 위치를 알려 줍니다.

한계

• 글자를 바꾸는 계산만 합니다. 주소가 실제로 열리는지, 안전한 주소인지는 확인하지 않으며 주소에 접속하지도 않습니다.
• 주소 전체 규칙은 URL 표준의 구성 요소별 집합만 적용합니다. 브라우저가 함께 하는 정리(스킴·호스트 소문자, ../ 정리, 기본 포트 빼기, 빈 경로에 / 붙이기)는 하지 않습니다. Chrome 151은 경로의 |도 %7C로 바꾸는 등 브라우저마다 몇 기호가 다를 수 있습니다.
• mailto:처럼 http·https가 아닌 주소도 경로 집합으로 바꿉니다. 이런 주소의 경로에 대한 URL 표준 규칙(불투명 경로)과는 공백 처리가 다를 수 있습니다.
• 자동 판별은 짐작입니다. 짧은 값이나 드문 글자(CP949 확장 한글, 일본어 판의 반각 가나)는 다른 인코딩으로 읽을 수 있으니 결과가 이상하면 직접 고릅니다. 옛 인코딩은 EUC-KR·Shift_JIS·Windows-1252만 다루며 EUC-JP·Big5 등은 없습니다.
• 주소 해부는 읽기와 복사만 합니다. 쿼리 항목을 고치거나 더하려면 URL 쿼리 ↔ 항목 표 도구를 씁니다. 언어·함수별 결과는 원문 앞 4,000자까지만 비교합니다.

기준: 인코딩 집합은 URL 표준(2026년 10월 19일 판)과 RFC 3986, 서명 규칙은 RFC 5849와 AWS 설명서, 함수 동작은 각 언어 설명서를 2026년 10월 22일에 확인했습니다. 표의 값은 이 도구와 PHP 8.5·Python 3.14·Node.js 26·Chromium 151에서 같은 결과를 확인했습니다.

출처

• 01WHATWG: URL Standard, Percent-encoded bytesfragment·query·special-query·path·userinfo·component·폼 집합, 옛 인코딩과 &#번호; 처리
• 02WHATWG: application/x-www-form-urlencoded폼 직렬화(공백 → +)와 풀기(+ → 공백)
• 03RFC 3986: Uniform Resource Identifier (URI): Generic Syntax2.1 대문자 16진수, 2.2 예약 문자, 2.3 비예약 문자, 2.4 두 번 인코딩 금지, 2.5 UTF-8, 부록 B 정규식
• 04ECMAScript: URI Handling FunctionsencodeURI·encodeURIComponent·decodeURIComponent의 정의
• 05MDN: encodeURIComponent()그대로 두는 글자, 짝 없는 서로게이트의 URIError
• 06RFC 5849 3.6: OAuth 1.0 Percent Encoding비예약 문자만 두고 나머지는 대문자 16진수로
• 07AWS: Create a signed AWS API requestUriEncode: 비예약 문자만 두고 공백은 %20, 대문자 16진수
• 08PHP: urlencode-_. 말고 모두 바꾸고 공백은 +, RFC 3986 방식은 rawurlencode
• 09Python: urllib.parse.quote_.-~는 그대로, safe 기본값 '/', quote_plus는 공백을 +로
• 10Java: URLEncoder. - * _는 그대로, 공백은 +, UTF-8 권장
• 11RFC 3492: Punycode국제화 도메인의 xn-- 이름
• 12WHATWG: Encoding StandardEUC-KR(CP949 확장 포함)·Shift_JIS·Windows-1252 해석

자주 묻는 질문

함께 쓰는 도구