왜 만들었나요
검색 결과 주소를 복사했더니 한글이 %EB%B6%80%EB%8F%99%EC%82%B0 같은 문자열로 바뀌어 뭐가 뭔지 알 수 없던 적이 있으실 겁니다. 로그를 볼 때마다 그걸 손으로 풀기 번거로워서, 붙여넣으면 바로 양쪽으로 바뀌게 만들었습니다.
URL 인코더
주소에 그대로 담을 수 없는 한글·공백·특수문자를 %XX 형태로 바꾸고, 반대로 되돌려 읽습니다.
로딩 중...
Note
입력한 주소나 텍스트는 서버로 전송되지 않습니다. 변환이 전부 브라우저 안에서 이뤄져, 내부 주소나 토큰이 든 링크도 기기 밖으로 나가지 않습니다.
사용 방법
-
위쪽에서 인코드·디코드 를 고릅니다. 한글을 주소에 담을 때는 인코드, 암호처럼 보이는 문자열을 읽을 때는 디코드입니다.
-
왼쪽 입력창에 주소나 텍스트를 붙여넣습니다. 샘플 버튼으로 시작해도 됩니다.
-
입력하는 즉시 오른쪽에 결과가 나옵니다. 복사 버튼으로 가져가세요.
이렇게 나옵니다
한글이 든 검색 주소를 넣으면 이렇게 나옵니다.
인코드
부동산 시세 → %EB%B6%80%EB%8F%99%EC%82%B0%20%EC%8B%9C%EC%84%B8
디코드
%EC%84%9C%EC%9A%B8 → 서울
알아두면 좋은 것
왜 한글을 그대로 못 쓰나
인터넷 주소 규격이 만들어질 때는 영문자·숫자·일부 기호만 쓰도록 정해졌습니다. 한글이나 공백은 그 목록에 없어서, 그대로 넣으면 시스템마다 다르게 해석하거나 주소가 끊깁니다.
그래서 이런 글자를 % 뒤에 숫자 두 자리로 바꿔 표현합니다. 한글 한 글자는 보통 %XX가 세 개 붙습니다.
자주 보는 변환
| 원래 | 바뀐 모습 |
|---|---|
| 공백 | %20 (또는 +) |
/ | %2F |
? | %3F |
& | %26 |
= | %3D |
# | %23 |
이런 경우에는
디코드했는데 여전히 `%25`가 보여요
두 번 인코딩된 경우입니다. %가 다시 인코딩되면 %25가 되므로, %2520은 원래 공백이 두 번 변환된 것입니다. 디코드를 한 번 더 돌리면 풀립니다.
공백이 `+`로 되어 있어요
주소 뒤 검색어 부분(? 뒤)에서는 공백을 +로 쓰는 방식이 오래전부터 함께 쓰였습니다. 둘 다 공백을 뜻하지만 위치에 따라 다르게 해석되니, 주소 경로에는 %20을 쓰는 게 안전합니다.
이 도구로는 안 되는 것
용어 설명
- 퍼센트 인코딩
주소에 못 쓰는 글자를
%+ 숫자 두 자리로 바꿔 적는 방식입니다.URL 인코딩이라고도 부르며, 주소·검색어·양식 전송 등 웹 곳곳에서 쓰입니다.
자주 묻는 질문
왜 한글이나 공백을 반드시 인코딩해야 하나요?
인터넷 표준 규약(RFC 3986)에 따르면 URL 주소에는 기본적으로 영문 알파벳, 숫자, 그리고 일부 제한된 기호(ASCII 문자셋)만 사용할 수 있도록 정의되어 있습니다. 한글, 이모지, 공백 등은 이 규칙에 포함되지 않기 때문에, 웹 브라우저와 서버가 이 문자들을 올바르게 인식하고 통신하기 위해서는 허용된 문자열의 조합(퍼센트 기호와 16진수 숫자)으로 변환하는 과정이 필수적입니다.
인코딩 결과에 보이는 % 기호와 숫자들은 무엇을 의미하나요?
이를 '퍼센트 인코딩(Percent-encoding)'이라고 부릅니다. % 기호 뒤에 붙는 두 자리 문자는 해당 원본 문자의 유니코드(UTF-8) 값을 16진수로 표현한 것입니다. 예를 들어 공백은 16진수로 20이기 때문에 '%20'으로 변환되며, 웹 서버는 이 '%20'을 전달받으면 다시 공백으로 해석하여 처리합니다.
공백이 %20이 아니라 + 기호로 변환되는 경우도 있던데 차이가 무엇인가요?
기본적인 웹 표준 URL 인코딩 규칙에서는 공백을 '%20'으로 변환하는 것이 맞습니다. 하지만 HTML 폼(Form) 데이터를 'application/x-www-form-urlencoded' 방식으로 서버에 제출할 때, 역사적인 이유로 공백이 덧셈 기호('+')로 변환되기도 합니다. 최신 웹 개발 환경과 API 통신에서는 혼란을 방지하기 위해 공백을 '%20'으로 통일하여 사용하는 것을 더욱 권장합니다.
마지막 업데이트: 2026년 8월