URL 파서

URL을 구성요소와 쿼리 파라미터로 분해합니다.

프로토콜	-
호스트명	-
포트	-
경로(path)	-
쿼리스트링	-
해시(#)	-
사용자정보	-
오리진	-

광고 랜딩 링크나 검색 결과 주소를 복사해 보면 물음표 뒤로 파라미터가 수십 개씩 붙어 있어 눈으로 읽기가 어렵습니다. 어떤 값이 어디에 들어 있는지 확인하려면 결국 하나씩 잘라 봐야 하죠. 이 도구는 URL 하나를 넣으면 구성요소별로 나누고, 쿼리 파라미터는 이름과 값을 표로 정리해 줍니다.

어떻게 계산되나요

사용 방법

입력창에 전체 URL을 붙여넣고 분석을 누르면 됩니다. https://user:pw@example.com:8080/path/page?q=한글&n=1#sec처럼 사용자 정보·포트·해시가 모두 붙은 주소도 그대로 처리됩니다.

분해되는 구성요소

항목	예시 값	설명
프로토콜	`https:`	통신 규약
호스트	`example.com`	도메인(또는 IP)
포트	`8080`	생략하면 기본 포트(http 80 / https 443)
origin	`https://example.com:8080`	프로토콜+호스트+포트, 보안 정책의 기준 단위
경로	`/path/page`	서버 내 위치
쿼리	`?q=...&n=1`	물음표 뒤 전체 문자열
해시	`#sec`	`#` 뒤 조각. 서버로 전송되지 않습니다
사용자 정보	`user:pw`	주소에 포함된 인증 정보(요즘은 거의 쓰지 않습니다)

쿼리 파라미터 표

쿼리 문자열은 &로 나눠 이름과 값을 표로 보여 줍니다. %ED%95%9C%EA%B8%80처럼 퍼센트 인코딩된 값은 디코딩한 형태로 함께 확인할 수 있어, 한글 검색어나 인코딩된 리다이렉트 주소를 읽을 때 편합니다.

자주 겪는 문제

프로토콜을 빼면 분석되지 않습니다. example.com/page는 https://를 앞에 붙여 주세요.
같은 이름의 파라미터가 여러 번 나올 수 있습니다(tag=a&tag=b). 오류가 아니라 다중 값입니다.
값 안에 또 다른 URL이 들어 있으면 대개 인코딩돼 있으므로, 디코딩된 값을 다시 넣어 한 번 더 분석하면 됩니다.

용어 정리

프로토콜(스킴): `https:`, `http:`처럼 어떤 방식으로 통신할지 정하는 앞부분입니다.
origin: 프로토콜·호스트·포트를 합친 값. 브라우저의 보안 정책(CORS, 쿠키 범위)이 이 단위로 적용됩니다.
쿼리 문자열: `?` 뒤에 `이름=값` 쌍을 `&`로 이어 붙인 부분. 서버에 전달되는 추가 정보입니다.
해시(프래그먼트): `#` 뒤 부분. 페이지 내 위치를 가리키며 서버로 전송되지 않습니다.
퍼센트 인코딩: 한글·공백처럼 URL에 그대로 쓸 수 없는 문자를 `%XX` 형태로 바꾼 표기입니다.

자주 묻는 질문

`example.com/page`를 넣으니 오류가 납니다.

프로토콜이 없으면 URL로 해석되지 않습니다. 앞에 `https://`를 붙여서 다시 분석해 보세요. 브라우저 주소창은 자동으로 붙여 주지만 파싱 규칙상으로는 필수 항목입니다.

포트가 비어 있는데 정상인가요?

네, URL에 포트를 명시하지 않으면 비어 있는 것이 정상입니다. 이때는 프로토콜의 기본 포트(http는 80, https는 443)가 쓰입니다.

쿼리 값의 한글이 `%EC%95%88`처럼 보입니다.

URL은 ASCII만 안전하게 전달할 수 있어 한글 등은 퍼센트 인코딩으로 바뀝니다. 이 도구는 파라미터 표에서 디코딩된 값을 함께 보여 주므로 원래 글자를 확인할 수 있습니다.

해시(`#`) 뒤 값은 서버 로그에 남나요?

남지 않습니다. 해시는 브라우저 안에서만 쓰이고 요청에 포함되지 않습니다. 그래서 유입 경로 추적이 필요한 값은 해시가 아니라 쿼리 파라미터에 담습니다.

같은 파라미터 이름이 두 번 나오는데 잘못된 링크인가요?

잘못된 것은 아닙니다. 체크박스처럼 값이 여러 개인 항목은 `tag=a&tag=b`로 반복해 보내는 것이 일반적입니다. 다만 서버가 어느 값을 쓰는지는 구현에 따라 다르니 확인이 필요합니다.

쿼리 파라미터