URL

정리됨

URL 클리너란?

친구에게 링크를 공유했는데 끝에 ?utm_source=newsletter&utm_campaign=spring_sale_2026&fbclid=IwAR0...가 잔뜩 붙어 있던 적, 있죠? 여기에 붙여넣으면 깨끗한 URL과 함께 정확히 무엇이 제거됐는지 JSON으로 정리해줍니다. 출력이 JSON이라 로그 한 줄, 테스트 픽스처, 또는 무엇이 정리됐는지 기록을 남기고 싶은 어디에든 그대로 복사해 쓸 수 있습니다.

이 페이지가 존재하는 이유는 Google Analytics, Facebook, HubSpot, Mailchimp 등 수십 개의 플랫폼이 공유하거나 저장하고 싶지 않은 것들을 URL에 붙이기 때문입니다. utm_* 파라미터는 Urchin Tracking Module에서 왔습니다 — Google이 2005년에 도입했고 지금은 어디에서나 볼 수 있습니다. fbclid는 Facebook의 클릭 식별자, gclid는 Google의 것입니다. 어느 것도 실제로 로드되는 페이지에는 영향이 없고 — 단지 도착 사이트에 어디서 왔는지를 알려줄 뿐입니다.

모든 처리는 표준 URLSearchParams API를 통해 브라우저에서 일어납니다. WHATWG URL Standard가 정의하는 바로 그 파서입니다. 업로드, 서버 호출, 로그 모두 없습니다. URL 클리닝은 결정적입니다 — 제거 목록은 소스에 들어 있어 직접 확인할 수 있고, 같은 입력은 항상 같은 출력을 만듭니다.

URL 클리너 사용법

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

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

왼쪽 패널에 URL을 떨어뜨리세요. 샘플을 클릭하면 utm_*, fbclid, gclid가 실제 쿼리 파라미터와 섞여 있는 현실적인 예시가 로드됩니다. 예시 URL:

https://shop.example.com/orders/ORD-1001?customer=Ava+Chen&status=active&utm_source=newsletter&utm_medium=email&utm_campaign=spring_sale_2026&fbclid=IwAR0abc123def456&gclid=Cj0KCQjwxyz

new URL(...)이 받아주는 것은 모두 동작합니다 — +, 퍼센트 인코딩, 중복 키, 해시 프래그먼트가 포함된 쿼리 문자열도 처리됩니다. 경로, 해시, 트래킹이 아닌 쿼리 파라미터는 그대로 보존됩니다.

정리된 URL과 제거된 항목 확인

오른쪽 패널에 JSON이 표시됩니다: cleaned는 트래킹이 제거된 URL, removed는 제거된 각 파라미터(키와 값)를 나열한 객체, removedCount는 총 개수입니다. 제거할 게 없으면 removed는 빈 객체이고 note 필드에 그 사실이 적힙니다. 입력하는 동안 실시간으로 갱신됩니다.

복사 또는 다운로드

복사를 누르면 JSON이 클립보드로, 다운로드를 누르면 .json 파일로 저장됩니다. 압축은 JSON을 한 줄로 만듭니다. 처음부터 다시 시작하려면 입력 패널의 지우기를 사용하세요. 정리된 URL 문자열만 필요하면 cleaned 필드의 값을 복사하세요.

이걸 실제로 쓰는 상황

공유 전 링크 정리

마케팅 이메일에서 연 탭의 링크를 Slack에서 친구에게 보내려고 합니다. URL 끝에 ?utm_source=newsletter&utm_campaign=spring_sale_2026이 붙어 있어요 — 친구는 어디서 왔는지 알 필요도 없고, 링크도 보기 흉합니다. 붙여넣고, cleaned 값을 복사해 보내세요. 먼저 구성 요소를 살펴보고 싶다면 URL 파서와 함께 쓰면 좋습니다.

데이터베이스에 표준 URL 저장

북마크 서비스나 가격 추적기 용도로 페이지를 인덱싱하고 있다고 합시다. 같은 상품을 utm_campaign 값만 다르게 두 번 방문한 건 두 페이지가 아니라 한 페이지입니다. URL을 DB에 쓰기 전에 트래커를 제거하지 않으면 중복이 쌓입니다. RFC 3986 명세는 이를 URL 정규화라고 부릅니다.

프라이버시 — 도착지에 리퍼러를 넘기지 않기

fbclid가 붙은 링크를 클릭하면, 도착 사이트에 "Facebook이 보냈다"는 사실과 함께 Facebook이 당신의 계정과 매칭할 수 있는 클릭 ID를 그대로 넘깁니다. Facebook 공식 문서도 fbclid를 광고 어트리뷰션용 클릭 식별자로 설명합니다. 방문 전(또는 링크 저장 전)에 제거하면 그 추적 경로가 끊깁니다.

고객 지원 티켓 정리

"이 링크를 클릭했더니 페이지가 깨졌어요" — 그런데 그 링크는 utm + gclid + HubSpot이 출시한 모든 트래킹 파라미터(__hssc, __hstc, _hsenc, hsa_*)가 다 붙어 600자나 됩니다. 붙여넣고, 정리된 URL을 복사해서, 그걸 버그 리포트에 다시 붙이세요. 이제야 진짜 경로가 보입니다.

자주 묻는 질문

정확히 어떤 것이 제거되나요?

utm_으로 시작하는 모든 것 (그러니까 utm_source, utm_medium, utm_campaign, utm_term, utm_content, 그리고 마케터가 추가한 임의의 utm_*) — 거기에 약 50개의 알려진 트래킹 파라미터를 명시적으로 등록한 목록: fbclid(Facebook), gclid와 dclid(Google Ads), mc_eid와 mc_cid(Mailchimp), _ga와 _gl(Google Analytics 크로스 도메인), igshid(Instagram), yclid(Yandex), __hsfp/__hssc/__hstc/_hsenc와 hsa_*(HubSpot), mtm_*와 pk_*/piwik_*(Matomo), vero_id, wickedid, _branch_match_id, _openstat 등. customer=Ava+Chen처럼 페이지에 의미가 있는 실제 쿼리 파라미터는 손대지 않고 그대로 둡니다.

경로나 해시를 변경하나요?

아닙니다. 쿼리 문자열만 건드립니다. 프로토콜, 호스트, 포트, 경로, 해시 프래그먼트는 그대로 통과합니다. 그래서 https://shop.example.com/orders/ORD-1001?utm_source=x#summary는 https://shop.example.com/orders/ORD-1001#summary가 됩니다 — 같은 경로, 같은 해시, 쿼리만 사라졌습니다.

제 자체 분석을 위해 utm_source는 남기고 싶다면요?

지금은 제거 목록이 페이지에 고정되어 있습니다. 커스텀 화이트리스트나 블랙리스트가 필요하다면 소스를 포크해서 사용하세요 — 파라미터 Set과 utm_* 정규식은 컴포넌트 상단에 있습니다. 향후 옵션으로 노출될 수 있지만, 여기 도착한 사람 대부분은 기본의 광범위한 동작을 원합니다.

fbclid는 왜 그렇게 길어요?

Facebook이 특정 광고와 (보통) 특정 사용자에게 클릭을 귀속시키기 위해 사용하는 불투명하고 서명된 식별자이기 때문입니다. 정확한 형식은 공개되지 않았지만, Wikipedia의 fbclid 문서에 자세히 정리되어 있습니다. gclid는 Google Ads용 동급 식별자입니다. 둘 다 공유하거나 저장하는 URL에서 안전하게 제거할 수 있고 — 실제 페이지를 로드하는 데는 필요하지 않습니다.

트래킹 파라미터가 없는 URL에서도 동작하나요?

네. 출력 JSON은 removedCount: 0, 빈 removed 객체, 아무것도 발견되지 않았다고 알리는 note 필드를 가집니다. cleaned URL은 입력과 바이트 단위로 동일합니다 (단, new URL().toString()이 정규화하는 부분 — 예를 들어 누락된 origin 끝 슬래시 추가 — 은 제외).

?utm_source=a&utm_source=b처럼 같은 키가 반복되면요?

둘 다 제거됩니다. URLSearchParams.delete(name)은 그 이름의 모든 항목을 제거하므로 중복은 문제가 되지 않습니다. removed 객체에는 값이 하나만 표시됩니다(가장 마지막에 파싱된 값). 다만 실제 URL에 utm_source를 두 번 넣는 사람은 거의 없습니다.

다른 URL 도구

클리닝은 한 가지 작업일 뿐입니다. 자연스럽게 함께 쓰는 도구는 다음과 같습니다: