URL 분석기 (URL 파서)

네이버 검색 URL 나눠 보기

2026-10-01 네이버 첫 화면에서 “부산 맛집”을 검색했을 때 주소창은 https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=%EB%B6%80%EC%82%B0+%EB%A7%9B%EC%A7%91&ackey=…였습니다. 매번 바뀌는 ackey를 뺀 주소를 붙여 넣으면 쿼리 파라미터는 다섯 개입니다. 검색어 query는 “부산 맛집”으로, +는 공백으로 디코딩됩니다. ie=utf8은 검색어를 UTF-8로 보냈다는 표시입니다. 안내가 하나도 나오지 않으면 브라우저가 이 URL을 고치지 않고 받아들였다는 뜻입니다.

EUC-KR로 만든 옛 링크

EUC-KR을 쓰는 오래된 게시판은 “부산”을 %BA%CE%BB%EA로 씁니다(Python의 '부산'.encode('euc-kr')로 확인할 수 있습니다). https://www.example.co.kr/board/list.asp?query=%BA%CE%BB%EA를 붙여 넣으면 query 값은 �λ�로 나오고 “UTF-8 아님” 표시가 붙습니다. 바이트 %CE%BB가 우연히 UTF-8로도 읽혀 그리스 문자 λ가 끼어든 것입니다. 브라우저와 URLSearchParams는 UTF-8로만 읽기 때문에, 이 표시가 보이면 링크를 만든 쪽의 문자 인코딩부터 확인하세요.

한글 도메인

https://한국인터넷진흥원.한국/을 붙여 넣으면 브라우저가 실제로 보내는 호스트는 xn--3e0bx5e6xzftae3gxzpskhile.xn--3e0b707e(Punycode)입니다. 도구는 호스트 이름 아래에 원래 표기를 함께 보여 줍니다. 한글만으로 된 라벨은 Unicode UTS #39의 기준에서 문제가 없어 경고가 없습니다. 반면 https://раураl.com/signin처럼 키릴 문자와 라틴 문자가 섞인 라벨에는 사칭 도메인 경고가 붙습니다.

브라우저와 서버가 다른 호스트를 읽는 URL

브라우저는 WHATWG URL 표준을, 서버 쪽 라이브러리는 RFC 3986을 따르는 경우가 많아서 입력에 따라 호스트가 달라집니다. http://evil.example\@good.example/login에서 브라우저는 http, https의 역슬래시를 슬래시로 읽으므로 호스트가 evil.example입니다. RFC 3986 부록 B대로 나누면 마지막 @ 앞이 사용자 정보가 되어 호스트는 good.example입니다. 2026-10-01 확인에서 Python 3.12의 urllib.parse.urlsplit()과 curl 8.7.1은 모두 good.example을 썼습니다. 호스트를 검사하는 코드와 요청을 보내는 코드가 다르면 허용하지 않은 호스트로 요청이 갈 수 있으므로, 도구가 경고합니다.

http://0x7f.1/admin도 같습니다. 브라우저의 IPv4 파서는 16진수, 8진수, 줄인 형식을 받아들여 127.0.0.1로 읽지만, RFC 3986에서는 0x7f.1이 이름입니다.

파라미터를 고쳐도 나머지는 그대로

쿼리를 URLSearchParams.toString()으로 다시 만들면 모든 파라미터가 다시 인코딩됩니다. “=”가 없는 flag는 flag=가 되고, %zz는 %25zz가 되며, 위의 EUC-KR 바이트는 %EF%BF%BD가 섞인 값으로 바뀌어 원래 링크로 쓸 수 없게 됩니다. 이 도구는 고치거나 추가한 파라미터만 인코딩하고 나머지는 원래 바이트를 그대로 둡니다. 항목 수정은 브라우저의 setter(url.port = … 등)로 처리하므로, 브라우저가 받아들인 결과가 그대로 보입니다.

다른 도구와 다른 점

2026-10-01 Bing의 “URL 분석” 검색에서 위쪽에 나오는 툴타다(tooltada.com)에 같은 URL 8개를 넣어 보았습니다. 쿼리를 편집하는 기능이 있지만, 아무것도 고치지 않았는데도 “재조합된 URL”에서 flag가 flag=로, %zz가 %25zz로, %E4%B8이 %EF%BF%BD로 바뀌었습니다. 역슬래시 URL은 호스트 evil.example, 0x7f.1은 127.0.0.1, localhost:3000/api는 프로토콜 localhost:로 나왔고 아무 안내도 없었습니다. example.com/path에는 “올바른 URL 형식이 아닙니다”라는 문구와 예시만 나왔습니다. 이 도구는 같은 결과에 왜 그렇게 되었는지 설명을 붙이고, 고치지 않은 부분은 바꾸지 않습니다.

제한 사항

• 결과는 사용 중인 브라우저의 것입니다. Node.js 24는 web-platform-tests의 URL 테스트 896개 중 888개를 통과합니다. 오래된 브라우저는 특이한 입력에서 결과가 다를 수 있습니다.
• Chromium(테스트에서는 Chrome 152)은 URL 표준이 금지하는 호스트 일부를 받아들입니다. http://exa mple.com/의 호스트는 exa%20mple.com으로 읽지만 Node.js는 이 URL을 거부합니다. 이때 도구는 표준으로는 유효하지 않다는 것과 문제 문자를 알려 주고, 브라우저의 읽기 결과도 보여 줍니다.
• RFC 3986 항목은 부록 B 정규식으로 나누고 문자를 검사할 뿐이며, 특정 라이브러리의 동작을 재현하지 않습니다. 서버 쪽은 실제 URL로 확인하세요.
• 공개 접미사 목록(Public Suffix List)이 없어 shop.example.co.kr을 하위 도메인과 등록 도메인으로 나누지 않습니다.
• 사칭 도메인 경고는 문자 체계가 섞인 라벨과, 라틴 문자와 닮은 키릴·그리스 문자로만 된 라벨이 대상입니다.
• 쿼리 파라미터 표에는 처음 500개까지만 보여 줍니다.

값 하나를 인코딩·디코딩하려면 URL 인코드 / 디코드, 호스트의 DNS 레코드를 보려면 DNS Lookup (DNS 확인), OAuth 인가 URL을 만들려면 PKCE 생성기, 페이지가 실제로 요청한 URL을 보려면 HAR 파일 분석기를 쓰세요.