URL

컴포넌트

URL 파서란?

URL을 붙여넣으면 도구가 진짜로 신경 쓰는 부분 — 프로토콜, 호스트, 포트, 경로, 쿼리 매개변수, 해시 — 으로 쪼개줍니다. 출력이 JSON이라 테스트 픽스처나 디버그 로그, 구조화된 형식으로 컴포넌트가 필요한 어디로든 바로 복사할 수 있습니다. 파서는 WHATWG URL 표준을 따르며, 모든 현대 브라우저가 내부적으로 사용하는 것입니다.

왜 파서가 필요할까요? 퍼센트 인코딩된 쿼리 매개변수 다섯 개와 해시 프래그먼트가 붙은 긴 URL을 읽는 게 고통스럽기 때문입니다. 브라우저는 이미 URL API로 이걸 할 줄 알지만, 빠르게 붙여넣고 보는 표면이 없습니다. 이게 그겁니다. 쿼리 매개변수도 디코딩됩니다 — %20은 공백으로, %5B는 [로, 반복된 키는 배열로 — URLSearchParams와 동일한 동작입니다.

모든 게 브라우저에서 실행됩니다. 업로드 없음, 서버 없음, 로그 없음. URL 파싱은 결정적입니다 — AI도 추측도 없이, RFC 3986이 정의하고 WHATWG 사양이 다듬은 동일한 알고리즘입니다.

URL 파서 사용법

세 단계. 각각 이 페이지의 버튼 하나에 대응합니다.

URL 붙여넣기 또는 샘플 불러오기

왼쪽 패널에 URL을 떨어뜨리세요. 샘플을 누르면 퍼센트 인코딩, 반복 쿼리 키, 해시 프래그먼트가 포함된 현실적인 예시가 로드됩니다. 예시 URL:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2#summary

URL 생성자가 받아들이는 것이라면 무엇이든 동작합니다 — <code>file://</code>, <code>mailto:</code>, 커스텀 스킴, IPv6 호스트, userinfo(<code>user:pass@host</code>) 포함.

컴포넌트 읽기

오른쪽 패널은 파싱된 URL을 JSON으로 보여줍니다: protocol, host, port, pathname, pathSegments(경로를 배열로 분할), searchParams(디코딩된 키-값 쌍, 반복 키는 배열), hash. 입력하는 동안 갱신됩니다.

복사 또는 다운로드

복사를 눌러 JSON을 클립보드로 보내거나 다운로드로 .json 파일로 저장합니다. 로그 한 줄에 필요하다면 압축으로 JSON을 한 줄로 압축할 수 있습니다. 입력 패널의 지우기로 다시 시작하세요.

실제로 쓰게 될 상황

리다이렉트와 분석 URL 디버깅

광고 추적 리다이렉트에서 온 쿼리 매개변수 12개짜리 URL은 주소창에서 읽을 수가 없습니다. 여기에 붙여넣으면 매개변수가 한 줄에 하나씩 디코딩되어 표시되고, 목적지 url 매개변수도 완전히 풀려서 나옵니다. 트래커를 벗겨내는 URL Cleaner(곧 출시)와 잘 어울립니다.

웹훅과 OAuth 콜백 URL 검사

OAuth 콜백과 웹훅 페이로드는 쿼리 문자열에 상태를 욱여넣습니다. 분리해보면 state 토큰이 빠졌는지, code가 잘렸는지, redirect_uri가 두 번 인코딩됐는지 한눈에 보입니다. RFC 6749가 이 매개변수들을 요구하며 이 도구는 그것들을 한 번에 모두 드러냅니다.

테스트 픽스처 만들기

URL을 상대로 테스트를 작성할 때, 보통 문자열이 아니라 구조화된 객체로 원합니다. URL을 붙여넣고 JSON을 복사해 픽스처 파일에 넣으세요. 오늘 다섯 번째로 protocol: 'https:'를 손으로 입력하지 않아도 됩니다.

고객 지원 티켓 점검

"이 링크 누르니까 깨졌어요" — 링크는 400자에 이중 인코딩된 슬래시까지. 파서는 브라우저가 보는 것을 정확히 보여줍니다. %252F가 리터럴 %2F인지, 프록시를 거치는 동안 두 번 인코딩된 경로 구분자인지까지요.

자주 묻는 질문

상대 URL에서도 동작하나요?

아니요 — URL 생성자는 절대 URL이 필요합니다(https://나 file:// 같은 프로토콜 포함). 상대 URL이라면 먼저 https://example.com 같은 베이스를 앞에 붙이고 결과에서 떼어내세요. WHATWG 사양에 브라우저가 내부적으로 사용하는 두 인자 형식(new URL(relative, base))이 설명되어 있습니다.

반복된 쿼리 키는 어떻게 처리하나요?

반복된 키는 배열로 합쳐집니다. 그래서 ?tag=red&tag=blue는 출력에서 "tag": ["red", "blue"]가 됩니다. 이는 대부분의 서버 프레임워크(Express, FastAPI, ASP.NET)가 쿼리 문자열을 파싱하는 방식과 일치합니다.

?items[]=1&items[]=2 같은 배열 대괄호 표기법은요?

파서는 대괄호를 키의 일부로 취급합니다 — 그래서 "items[]": ["1", "2"]로 보입니다. 와이어상의 바이트에 정직한 결과죠. 프레임워크별 디코더(PHP, Rails, qs.js)가 필요하면 파싱된 출력에 대해 후처리를 하세요.

URL의 자격 증명(user:pass@host)을 여기에 붙여넣어도 안전한가요?

파싱은 전적으로 브라우저에서 일어나며, URL이 기기를 떠나지 않습니다. 다만 자격 증명을 URL에 넣는 건 일반적으로 권장되지 않으며(RFC 3986 §3.2.1이 보안 위험을 지적), 대부분의 브라우저는 조용히 제거합니다. 그래도 붙여넣으면 출력에 username과 password 필드가 표시됩니다.

국제화 도메인 이름(IDN)도 처리하나요?

브라우저의 URL 생성자는 IDN 도메인을 처리하지만, 출력은 Unicode 형식이 아니라 Punycode 형식(xn--...)으로 표시될 수 있습니다. 그게 실제로 와이어로 전송되는 형태입니다. 둘 사이를 변환해야 한다면, 전용 Punycode 도구가 곧 이 섹션에 추가됩니다.

왜 출력이 "JSON"이 아니라 "컴포넌트"라고 불리나요?

JSON 맞습니다 — 다만 프레이밍이 중요합니다. 출력은 URL의 부분들이 구조화된 것입니다. 페이지를 "URL → JSON 변환기"로 보면 요점을 놓칩니다: 가치는 분해에 있지 형식에 있지 않습니다.

다른 URL 및 JSON 도구

파싱은 하나의 동작입니다. 자연스럽게 함께 쓸 수 있는 것들: