URL 인코딩 및 디코딩
URL용 텍스트를 퍼센트 인코딩하거나 `%HH` 시퀀스를 문자로 되돌립니다. 컴포넌트 모드와 전체 URI 모드를 비교하고 `%20`과 `+`가 같지 않은 이유를 확인하세요.
모든 계산은 브라우저에서 실행됩니다. 입력한 내용은 서버로 전송되지 않습니다.
입력하면 결과가 갱신됩니다. Ctrl/Cmd+Enter로 주요 결과 복사.
결과
—
비트 보기
풀이 보기
URL 인코딩·디코딩은 RFC 3986 퍼센트 인코딩을 텍스트에 적용하고 %HH 시퀀스를 문자로 되돌립니다. 컴포넌트 모드는 /, ?, & 같은 예약 문자를 인코딩해 단일 쿼리 매개변수 안에 안전하게 둘 수 있습니다. 전체 URI 모드는 구조적 구분자를 유지해 완전한 주소가 사용 가능한 링크로 남습니다. 공백 처리는 %20과 폼 인코딩 플러스 기호를 모두 지원합니다.
인코딩과 디코딩은 모두 브라우저에서 실행됩니다. 붙여 넣은 내용이 서버로 전송되지 않습니다.
URL에서 안전하게 쓰도록 텍스트 인코딩하기
퍼센트 인코딩은 안전하지 않거나 예약된 바이트를 퍼센트 기호와 두 자리 16진수로 바꿉니다. 숫자는 보통 UTF-8의 바이트 값입니다. 문자열을 입력하고 컴포넌트 또는 전체 URI 모드를 선택한 뒤, 인코딩 결과를 쿼리 문자열, 경로 세그먼트, 리다이렉트 대상에 복사합니다.
비예약 집합에 이미 있는 문자는 그대로 통과합니다. 나머지는 컴포넌트 모드에서 %HH 시퀀스가 됩니다. 디코딩에 같은 규칙을 쓰면 가역적입니다. 폼 인코딩 플러스 기호와 경로 스타일 %20을 섞는 것이 깨진 왕복의 흔한 원인입니다.
퍼센트 인코딩된 문자열 디코딩하기
디코딩은 % 뒤에 16진수 두 자리가 오는 각 위치를 찾아 그 쌍을 바이트로 바꾸고, 선택한 문자 인코딩으로 원래 텍스트를 재구성합니다. % 하나만 있거나 16진이 아닌 숫자가 오면 오류입니다. 입력이 application/x-www-form-urlencoded 본문에서 왔다면 플러스 기호를 공백으로 처리할 수 있습니다.
중첩 인코딩은 값이 두 번 인코딩되었을 때 나타납니다. 한 번 디코딩해도 리터럴 %를 나타내는 %25 시퀀스가 남을 수 있습니다. 두 번째 층이 의도적일 때만 다시 디코딩하세요. 맹목적 이중 디코딩은 실제 % 문자를 포함한 데이터를 손상시킵니다.
예약 문자와 비예약 문자 이해하기
RFC 3986은 ASCII를 URI에서 인코딩이 필요 없는 비예약 문자와 구분자 같은 구조적 의미를 가진 예약 문자로 나눕니다. 비예약 영문, 숫자, -_.~는 리터럴로 남습니다. /, ?, & 같은 예약 기호는 URL을 틀 잡는 구문이 아니라 데이터로 나타날 때 퍼센트 인코딩해야 합니다.
비예약: A부터 Z, a부터 z, 0부터 9, 하이픈 -, 밑줄 _, 마침표 ., 물결 ~
예약 (gen-delims): `: / ?
예약 (sub-delims): ! $ & ' ( ) * + , ; =
비예약 문자는 리터럴로 남습니다. 예약 문자는 구분자가 아니라 데이터로 나타날 때 인코딩해야 합니다. 매개변수 값 안의 물음표는 데이터입니다. 쿼리 문자열을 시작하는 물음표는 구조입니다. 모드 선택으로 계산기가 각 문자의 역할을 판단합니다.
전체 URL과 단일 매개변수 인코딩하기
전체 URI 인코딩은 JavaScript encodeURI와 유사하게 구조 문자를 그대로 두어 https://와 경로 슬래시가 살아 남습니다. 컴포넌트 인코딩은 encodeURIComponent와 유사하게 그 문자들을 인코딩해 값을 주변 URL을 깨지 않고 매개변수 안에 둘 수 있습니다. 잘못된 모드를 고르면 링크가 깨지거나 쿼리를 잘못 나누는 구분자가 남습니다.
| 입력 | 전체 URI 스타일 | 컴포넌트 스타일 |
|---|---|---|
https://example.com/a b | https://example.com/a%20b | https%3A%2F%2Fexample.com%2Fa%20b |
red&blue | red&blue | red%26blue |
a=b | a=b | a%3Db |
컴포넌트 모드로 전체 URL을 인코딩하면 링크로서 깨집니다. 스킴 콜론과 슬래시가 %3A와 %2F가 됩니다. 전체 URI 모드로 단일 매개변수를 인코딩하면 &와 =가 그대로 남아 쿼리가 잘못 분할됩니다. 문자열이 차지할 자리에 맞는 모드를 고르세요.
슬래시와 물음표 인코딩하기
픽스처 문자열 / and ?는 컴포넌트 모드에서 %2F%20and%20%3F가 됩니다. 슬래시와 물음표는 예약 구분자이지만 여기서는 페이로드 텍스트로 취급되므로 각각 이스케이프됩니다. 공백은 %20이 되고 and의 글자는 비예약이라 왼쪽에서 오른쪽으로 그대로 통과합니다.
| 문자 | 이유 | 인코딩 결과 |
|---|---|---|
/ | 예약 경로 구분자 | %2F |
| 공백 | 비예약 아님 | %20 |
a, n, d | 비예약 글자 | 변경 없음 |
? | 예약 쿼리 구분자 | %3F |
왼쪽에서 오른쪽으로: / 인코딩, 공백 인코딩, and 통과, 공백 인코딩, ? 인코딩. 결과 %2F%20and%20%3F는 예를 들어 q라는 이름의 쿼리 매개변수에 안전하게 넣을 수 있습니다. 같은 문자열에 전체 URI 모드를 쓰면 /와 ?가 리터럴로 남는데, 이는 그 문자들이 구조를 의미할 때만 맞습니다.
%20과 플러스 기호 이해하기
공백은 URI 경로와 RFC 3986을 따르는 현대 쿼리 문자열에서 %20으로 인코딩됩니다. application/x-www-form-urlencoded로 제출하는 HTML 폼은 역사적으로 공백을 +로 인코딩해 왔습니다. 두 관례 모두 실제 트래픽에 나타나며, 동일시하는 것이 혼합 입력을 디코딩할 때 가장 흔한 공백 인코딩 버그입니다.
| 맥락 | 공백 인코딩 |
|---|---|
| 경로 세그먼트 | %20 |
| RFC 3986 쿼리 | %20 |
| 폼 본문 / 레거시 쿼리 | + |
데이터의 리터럴 플러스는 %2B로 인코딩해야 하며, 그렇지 않으면 폼 디코더가 공백으로 처리합니다. 계산기는 어떤 공백 관례가 활성인지 표시해, 폼 모드에서 디코딩된 +를 플러스 문자와 혼동하지 않고 경로 모드에서 %20을 거부하지 않습니다.
URL을 구성 요소로 나누기
일반적인 URL에는 스킴, 호스트, 선택적 포트, 경로, 쿼리 문자열, 프래그먼트가 있으며 인코딩 규칙은 부분마다 다릅니다. ://, /, ?, &, =, # 같은 구조 구분자는 주소를 틀 잡을 때 리터럴로 남습니다.
매개변수 이름, 매개변수 값, 데이터를 담는 경로 세그먼트는 구분자로 합치기 전에 컴포넌트 모드로 개별 인코딩합니다.
https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘ └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
scheme host path query fragment| 부분 | 역할 |
|---|---|
| 스킴 | https 같은 프로토콜 |
| 호스트 | 도메인 또는 IP, 선택적 포트 포함 |
| 경로 | 리소스 위치, 슬래시로 구분 |
| 쿼리 | ? 뒤의 매개변수 목록, &로 연결 |
| 프래그먼트 | # 뒤의 클라이언트 측 위치, 요청 URI처럼 서버로 전송되지 않음 |
매개변수 이름과 값을 컴포넌트 모드로 개별 인코딩한 뒤 리터럴 &와 =로 연결합니다. 경로 세그먼트에 공백이나 예약 문자가 있으면 개별 인코딩하고 세그먼트를 나누는 슬래시는 리터럴로 유지합니다.
문자 인코딩 표 읽기
아래 표는 UTF-8 바이트 인코딩에서 흔한 예약 및 안전하지 않은 문자와 퍼센트 형태를 나열합니다. 공백은 %20, 앰퍼샌드는 %26, 해시는 %23이 됩니다. 비 ASCII 문자는 추상 글리프 하나가 아니라 각 UTF-8 바이트를 따로 인코딩하므로 여러 %HH 단위로 펼쳐집니다.
| 문자 | 퍼센트 | 비고 |
|---|---|---|
| 공백 | %20 | 폼 인코딩에서는 +도 |
! | %21 | |
# | %23 | 프래그먼트 구분자 |
$ | %24 | |
& | %26 | 쿼리 쌍 구분자 |
' | %27 | |
( | %28 | |
) | %29 | |
+ | %2B | 리터럴 플러스 |
, | %2C | |
/ | %2F | 경로 구분자 |
: | %3A | 스킴 / 호스트 구분자 |
; | %3B | |
= | %3D | 매개변수 할당 |
? | %3F | 쿼리 시작 |
@ | %40 | 사용자 정보 구분자 |
[ | %5B | |
] | %5D |
비 ASCII 텍스트는 먼저 UTF-8 바이트로 표현된 뒤 각 바이트가 퍼센트 인코딩됩니다. 한 글자가 두세 %HH 단위로 펼쳐질 수 있습니다. Shift JIS 같은 레거시 세트의 문자 인코딩 심층 설명은 Base64 도구에 있으며, 이 페이지는 카탈로그를 반복하지 않고 링크합니다.
자주 묻는 질문
퍼센트 인코딩이란?
퍼센트 인코딩은 바이트를 그 바이트 값의 16진수 두 자리 뒤에 %를 붙여 바꿉니다. 예약 및 비 ASCII 문자가 구문으로 읽히지 않고 URL 안을 통과하게 합니다. 디코딩은 치환을 되돌립니다.
컴포넌트 인코딩은 언제 써야 하나?
단일 매개변수 이름이나 값, 순수 데이터인 경로 세그먼트, 구조 구분자 옆에 삽입할 임의 문자열에 사용합니다. /, ?, &, =를 인코딩해 URL을 나누지 못하게 합니다.
전체 URI 인코딩은 언제 써야 하나?
입력이 이미 완전한 URL이고 공백 같은 불법 문자만 바꿔야 할 때 사용합니다. 구조적 콜론과 슬래시는 리터럴로 남아 결과가 클릭 가능한 주소로 유지됩니다.
/ and ?가 왜 %2F%20and%20%3F가 되나?
컴포넌트 모드에서 슬래시와 물음표가 데이터로 취급되어 %2F와 %3F로 인코딩됩니다. 공백은 %20이 되고 and의 글자는 비예약이라 그대로입니다.
+는 %20과 같나?
아니요. %20은 RFC 3986에서 공백의 인코딩입니다. +가 공백을 의미하는 것은 application/x-www-form-urlencoded 데이터뿐입니다. 리터럴 플러스는 %2B여야 하며 그렇지 않으면 폼 디코더가 공백으로 바꿉니다.
인코딩이 필요 없는 문자는?
비예약 집합: 영문, 숫자, 하이픈, 밑줄, 마침표, 물결입니다. 이 문자들은 두 모드 모두에서 리터럴로 남습니다. 인코딩해도 되지만 불필요한 길이만 늘어납니다.
비 ASCII 문자는 어떻게 인코딩되나?
먼저 UTF-8 바이트로 변환한 뒤 각 바이트를 퍼센트 인코딩합니다. 보이는 한 글자가 여러 %HH 시퀀스가 될 수 있습니다. 디코딩은 UTF-8로 원래 텍스트를 재구성해야 합니다.
두 번 디코딩하면 깨진 URL이 고쳐지나?
값이 의도적으로 두 번 인코딩된 경우에만 그렇습니다. 그렇지 않으면 두 번째 패스가 데이터 일부였던 리터럴 % 시퀀스를 손상시킵니다. 한 번 디코딩하고 확인한 뒤 %25 패턴으로 두 번째 층이 보일 때만 다시 디코딩하세요.
Base64와 같나?
아니요. 퍼센트 인코딩은 URI용 문자 이스케이프입니다. Base64는 임의 바이트를 텍스트 프로토콜 전송용 64문자 알파벳으로 매핑합니다. 각각 목적에 맞게 쓰세요.
붙여 넣은 URL이 업로드되나?
아니요. 인코딩과 디코딩은 브라우저에서만 실행됩니다. 토큰이나 세션 프래그먼트를 포함한 쿼리 문자열도 이 도구가 서버로 전송하지 않습니다.
요약
URL 인코딩·디코딩은 RFC 3986 규칙 아래 텍스트를 퍼센트 인코딩·디코딩하며, 전체 URI와 개별 컴포넌트용 모드를 분리합니다. 픽스처 / and ?는 컴포넌트 모드에서 %2F%20and%20%3F가 됩니다. 공백은 URI 맥락에서 %20을 쓰고 폼 인코딩에서는 +를 쓸 수 있으며, 이는 다른 관례입니다.
예약 문자는 구조로 리터럴로 남을 때만 의미를 유지하고, 페이로드일 때는 인코딩합니다. 모든 작업은 기기에서만 이루어집니다.