URL 파서
URL을 프로토콜·호스트·경로·쿼리 파라미터로 분해
로컬 실행
loading…
이 도구에 대해
URL을 붙여넣으면 낱낱이 분해됩니다. 프로토콜, 호스트, 포트, 경로, 프래그먼트, 그리고 디코딩된 키-값 테이블로 정리된 모든 쿼리 파라미터까지. 브라우저가 탐색에 쓰는 것과 같은 WHATWG URL 파서를 사용하므로, 여기서 보는 해석이 곧 브라우저가 실제로 적용할 해석입니다. 기본 포트가 생략되고 경로가 정규화되는 엣지 케이스까지 포함해서요.
가장 자주 쓰게 될 부분은 쿼리 파라미터 테이블입니다. 긴 OAuth 리디렉션, 분석 태그가 붙은 링크, API 호출이 한눈에 읽히게 되고, 각 값은 이미 퍼센트 디코딩되어 있습니다. 스킴 없는 도메인만 붙여넣어도 되며, 파싱 시 https:// 가 가정됩니다.
URL 인코더와 자연스럽게 짝을 이룹니다. 여기서 URL을 파싱해 필요한 파라미터를 찾고, 값을 수정한 뒤, 저쪽에서 다시 인코딩하세요.
자주 묻는 질문
- 왜 파싱된 URL이 붙여넣은 것과 조금 다른가요?
- WHATWG 파서가 정규화하기 때문입니다. 스킴과 호스트를 소문자로 만들고, 기본 포트(https의 :443)를 제거하고, ./ 와 ../ 경로 세그먼트를 해석하고, 필요한 문자를 인코딩합니다. 보이는 것은 서버와 브라우저가 합의한 정규 형식입니다.
- 쿼리 키가 중복된 URL도 처리하나요?
- 네. 등장하는 모든 항목이 순서대로 각각 하나의 행으로 나열됩니다. 중복 키는 합법이며 흔합니다. 많은 API가 이를 배열로 읽습니다(?tag=a&tag=b).
- host와 hostname은 무엇이 다른가요?
- hostname은 도메인만 가리킵니다(example.com). host는 명시적인 비기본 포트를 포함합니다(example.com:8080). 포트가 스킴의 기본값이면 포트가 생략되어 둘이 같아 보입니다.
- 프래그먼트(#...)는 서버로 전송되나요?
- 아니요. # 뒤의 모든 것은 브라우저에 남으며 서버는 절대 보지 못합니다. 싱글 페이지 앱이 역사적으로 클라이언트 측 라우팅에 이를 사용한 이유이고, # 뒤에 놓인 분석 파라미터가 백엔드에 보이지 않는 이유이기도 합니다.