URL

검증 리포트

URL 검증기란?

URL을 붙여 넣으면 구조화된 리포트가 돌아옵니다. 형식이 올바른지, 각 구성 요소가 어떻게 보이는지, 무엇을 주의해야 하는지. 검증기는 URL을 브라우저의 네이티브 URL 생성자를 통해 실행하며 — WHATWG URL 표준을 구현 — 그 위에 구성 요소별 검사를 얹습니다.

"유효한 URL"이란 단순히 파싱이 되는 URL이 아닙니다. http://10.0.0.5/admin?token=abc123 같은 URL은 잘 파싱되지만, 아마 플래그를 띄우고 싶은 세 가지가 있습니다. https://가 아니라 http://인 점, 호스트가 IP 리터럴인 점, 쿼리 문자열에 토큰이 들어 있는 점입니다. 검증기는 이 세 가지를 합/불 체크와 별개로 경고로 표면화합니다. 기본 구문 규칙은 RFC 3986에서 오고, 호스트 명명에 관한 고려는 RFC 1034와 운영 경험에서 옵니다.

출력은 JSON이라 CI 스크립트나 디버그 로그로 그대로 흘려보낼 수 있습니다. 모든 작업은 브라우저에서 실행됩니다 — URL은 절대 컴퓨터 밖으로 나가지 않습니다. 검증 레이어 없이 URL을 구성 요소로 분해하고 싶다면 URL Parser를 대신 사용하세요. 국제화 도메인 이름은 IDNA 규칙에 따라 처리됩니다.

URL 검증기 사용법

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

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

왼쪽 패널에 URL을 떨어뜨리세요. 샘플을 클릭하면 퍼센트 인코딩된 쿼리 매개변수가 있는 깔끔하고 잘 형성된 URL을 불러옵니다:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active

검증기는 입력에 따라 업데이트됩니다. 엣지 케이스를 시도해 보세요: http:// URL, IP 리터럴 호스트, 자격 증명이 있는 URL, 단일 레이블 호스트(TLD 없음), Punycode 도메인. 각각 다른 경고를 띄웁니다.

리포트 읽기

오른쪽 패널은 세 개의 최상위 필드가 있는 JSON 리포트를 보여 줍니다: isValid(URL이 일단 파싱되었는지), checks(구성 요소별 상태 — 프로토콜, 호스트네임, 포트, 경로명), warnings(구문 오류는 아니지만 신경 쓰일 만한 권고 사항).

복사 또는 다운로드

복사를 클릭해 JSON 리포트를 클립보드로 보내거나, 다운로드로 .json으로 저장하세요. 로그 항목용으로 필요하다면 압축이 리포트를 한 줄로 압축합니다.

실제로 쓸 만한 상황

배포 전 설정 파일 감사

서비스 설정에 40개의 URL이 들어 있습니다 — 웹훅 엔드포인트, OAuth 콜백, 서드파티 통합. 그중 하나는 잊혀진 테스트의 비밀번호가 박혀 있고, 두 개는 여전히 http:// 스테이징 호스트를 가리킵니다. 하나씩 검증기에 통과시키면 출시 전에 셋 다 잡을 수 있습니다. URL 형식에 대한 의존성은 리다이렉트 URI에 관한 OAuth 2.0 명세에도 나타납니다.

폼에서 사용자가 제출한 URL 검토

사용자가 "웹사이트" 필드에 보낸 게 알고 보니 example입니다 — 프로토콜 없음, TLD 없음, 그냥 단어 한 개. 또는 https://192.168.1.5 — 유효해 보이고 파싱도 유효하지만, 그걸 프로필 링크로 렌더링하고 싶지는 거의 확실히 않을 겁니다. 검증기는 둘 다 표면화합니다: 첫 번째에는 TLD 누락 경고, 두 번째에는 IP 리터럴 호스트 경고.

리다이렉트가 실패하는 이유 진단

OAuth 콜백이 "invalid redirect_uri"로 400을 반환합니다. 브라우저에서는 URL이 멀쩡해 보입니다. 검증기에 붙여 넣으면 발견됩니다: 경로에 리터럴 공백이 있고, 인증 제공자는 정규화 후 바이트 단위로 문자열을 비교합니다. 경고("path contains unencoded space")가 답이었던 겁니다.

Punycode vs Unicode 불일치 발견

리포트에서 münchen.example.com을 기대했는데 대신 xn--mnchen-3ya.example.com이 보였습니다. 그게 Punycode 형식 — 회선으로 전송되는 형태 — 이고, 검증기가 이를 표시해 원래 입력에 비ASCII 문자가 있었음을 알려 줍니다. 버그 리포트의 사용자가 IDN 도메인에서 URL을 복사·붙여넣기했을 때 유용합니다.

자주 묻는 질문

여기서 "유효"가 실제로 무슨 뜻인가요?

두 계층입니다. isValid: true는 브라우저의 URL 생성자가 입력을 받아들였다는 의미 — 즉 구문이 WHATWG URL 표준에 맞게 잘 형성되었다는 뜻입니다. warnings는 별개입니다: 구문상으로는 유효하지만 아마 원하는 것이 아닐 만한 사항들(안전하지 않은 프로토콜, IP 리터럴, 임베디드 자격 증명, TLD 누락 등). URL이 유효하면서 동시에 경고를 가질 수도 있습니다.

URL이 실제로 무언가에 도달하는지 확인하나요?

아니요 — 그건 네트워크 요청이 필요하고, 이 도구는 외부 호출 없이 브라우저에서 전부 실행됩니다. 검증기는 구문과 표면적 휴리스틱만 검사합니다. 도달성 검사는 curl -I나 전용 가동 시간 도구를 사용하세요.

http://example.com이 왜 경고로 표시되나요?

왜냐하면 2026년에 평문 URL은 거의 항상 실수이기 때문입니다 — 현대 브라우저는 http://를 통해 폼을 제출하기 전에 사용자에게 경고하고, Google의 "why HTTPS matters"가 긴 설명을 다루며, HSTS 프리로드된 도메인은 HTTP로는 아예 로드를 거부합니다. 경고는 권고 사항입니다. 정말 http://를 의도한다면(레거시 인트라넷, 로컬 개발), 무시하세요.

/api/orders 같은 상대 URL은 어떻게 되나요?

URL 생성자는 절대 URL이 필요합니다 — 베이스 없이는 프로토콜이나 호스트를 판별할 수 없습니다. 그 경우 검증기는 명확한 오류와 함께 isValid: false를 반환합니다. 상대 URL을 검증하려면 먼저 https://example.com 같은 베이스를 앞에 붙이세요.

URL에 자격 증명을 넣는 건 항상 잘못인가요?

거의 그렇습니다. RFC 3986 §3.2.1는 보안상의 이유로 URL의 자격 증명이 비권장임을 명시합니다. 그것들은 브라우저 기록, 서버 액세스 로그, 프록시 캐시에 남습니다. 현대 브라우저는 클립보드 붙여넣기에서 조용히 그것들을 제거합니다. 검증기는 그것들이 새어 나가서는 안 될 곳에 새기 전에 명시적인 기록을 남길 수 있도록 표시합니다.

IDN 도메인을 신경 쓰나요?

예 — 검증기는 호스트네임이 Punycode 형식(xn--...)인지 순수 ASCII인지 표시합니다. 브라우저는 사용자에게는 Unicode 형식을 표시하면서 회선에는 Punycode 형식을 전송할 수 있는데, 이것이 IDN 호모그래프 공격의 근원입니다. Punycode를 표면화하는 것은 작지만 유용한 신호입니다.

다른 URL & JSON 도구

검증은 하나의 작업입니다. 자연스럽게 짝을 이루는 도구들은 다음과 같습니다: