설정 (JSON)

URL

URL 빌더가 뭔가요?

URL의 각 부분(프로토콜, 호스트, 경로, 쿼리 파라미터, 해시)을 기술한 JSON 객체를 넘기면, 도구가 적절히 퍼센트 인코딩된 URL을 돌려줍니다. 내부에서는 브라우저의 네이티브 URL API를 쓰기 때문에, 직접 JavaScript로 URL을 만들었을 때와 정확히 똑같은 출력이 나옵니다.

왜 필요하냐면, URL을 손으로 만드는 곳에 버그가 숨어 있어서 그렇습니다. 고객 이름의 공백을 인코딩하지 않거나, 이미 인코딩된 슬래시를 이중 인코딩하거나, ?와 &를 헷갈리거나, %20 대신 +를 써서 값이 사라집니다. WHATWG URL 명세는 각 입력에 대한 정답을 정확히 하나 정의하고 있고, 여기서 받는 게 바로 그 답이에요. 반복 쿼리 키(예: tag=red&tag=blue)는 배열을 넘기면 지원됩니다 — URLSearchParams가 받는 형식과 같습니다.

전부 브라우저에서 동작합니다. JSON 설정과 조립된 URL은 절대 컴퓨터 밖으로 나가지 않아요. 인코딩 규칙은 RFC 3986과 그 위에 더해진 WHATWG의 보완에서 직접 가져옵니다. 구조화된 폼을 통해 URL을 왕복시키고 싶을 때는 URL 파서와 함께 쓰세요.

URL 빌더 사용법

세 단계. 각 단계는 이 페이지의 버튼 하나에 해당합니다.

JSON 설정 붙여넣기

왼쪽에 URL 부분들을 기술한 JSON 객체를 붙여넣으세요. protocol과 host는 필수, 나머지는 선택입니다. 여러 쿼리 파라미터와 해시가 들어간 현실적인 예제를 불러오려면 샘플을 누르세요:

{
  "protocol": "https",
  "host": "api.shop.example.com",
  "pathname": "/v1/orders",
  "searchParams": {
    "customer": "Ava Chen",
    "status": "active",
    "total[gte]": "49.99",
    "page": "2"
  },
  "hash": "summary"
}

선택 필드: port, username, password, hash. searchParams 안에서 문자열은 값 하나, 배열은 반복 키입니다.

조립된 URL 확인

오른쪽 패널에 조립된 URL 문자열이 표시됩니다. 쿼리 문자열에서 공백은 +로, 대괄호는 %5B/%5D로, 경로는 정규화됩니다 — URL 표준이 정의하는 인코딩 그대로입니다. 입력하는 동안 실시간으로 갱신돼요.

복사 또는 다운로드

복사를 눌러 클립보드로 보내거나, 다운로드로 텍스트 파일로 저장하세요. 처음부터 다시 시작하려면 입력 패널의 지우기를 사용하세요.

실제로 쓰게 될 상황

HTTP 클라이언트용 테스트 픽스처 만들기

/v1/orders를 쿼리 파라미터 8개로 호출하는 테스트를 작성 중인데, 그중 두 개에 공백이 있고 하나는 반복됩니다. 인코딩된 URL을 손으로 테스트에 적는 건 실수가 잦아요. 실제 요청 로그에서 가져온 JSON 객체로부터 만들어서, 결과 URL을 어서션에 붙여넣으세요. 끝.

OAuth 인증 URL 만들기

OAuth 인증 URL은 client_id, redirect_uri, scope, state, response_type, code_challenge를 쿼리 문자열에 욱여넣습니다. RFC 6749는 정확한 파라미터 이름과, 전체 URL이 다시 인코딩되기 전에 이미 한 번 인코딩된 redirect_uri를 요구합니다. 빌더가 이걸 투명하게 처리합니다 — 원시 값을 주면 알아서 올바르게 만듭니다.

스크립트에서 분석/공유 URL 생성

UTM 파라미터가 붙은 캠페인 URL을 생성할 때, 값은 종종 스프레드시트에서 옵니다. utm_campaign 값에는 공백, 앰퍼샌드, 가끔 이모지가 들어갑니다. 문자열 템플릿보다 URL 생성자에게 인코딩을 맡기는 편이 안전합니다. 출력은 Node의 URL 모듈이 만드는 것과 동일해요.

고객 지원 티켓의 버그 재현

고객이 q=résumé writer로 검색하면 API에서 500이 난다고 신고했습니다. 같은 요청을 정확히 재현하고 싶어요. JSON에서 URL을 만들고 curl로 보내세요. e의 악센트와 공백 모두 브라우저가 보냈을 방식 그대로 인코딩됩니다 — 추측 없이.

자주 묻는 질문

URL 빌더와 직접 문자열을 이어붙이는 것의 차이는요?

인코딩입니다. https://api.example.com/orders?customer=Ava Chen은 유효한 URL이 아니에요 — 공백이 깨뜨립니다. 빌더는 내부적으로 URLSearchParams를 사용해 그 공백을 쿼리에서는 +, 경로에서는 %20로 인코딩합니다. 손으로 한 문자열 결합은 조만간 둘 중 하나에서 틀립니다.

쿼리 파라미터를 두 번 보내려면(예: ?tag=red&tag=blue)?

값으로 배열을 쓰세요: "tag": ["red", "blue"]. 빌더는 제공한 순서대로 tag=red&tag=blue를 출력합니다. URLSearchParams 명세와 일치합니다.

프로토콜 뒤의 콜론(https:)을 포함해야 하나요, 아니면 그냥 https?

둘 다 됩니다. 빌더는 "protocol": "https"와 "protocol": "https:"를 모두 https:로 정규화합니다. http, ftp, mailto, 사용자 정의 스킴도 똑같아요.

URL에 자격 증명(사용자/비밀번호)을 포함할 수 있나요?

네 — 설정에 "username"과 "password"를 넣으세요. 호스트 앞에 user:pass@host 형태로 나타납니다. 다만 RFC 3986 §3.2.1는 운영용 URL에서 이렇게 쓰지 말라고 경고합니다 — 브라우저 기록, 서버 로그, 프록시 캐시에 남기 때문이에요.

왜 공백이 %20이 아니라 +로 바뀌나요?

쿼리 컴포넌트의 공백은 보통 application/x-www-form-urlencoded 규칙에 따라 +로 인코딩됩니다 — URLSearchParams가 출력하는 방식이에요. 경로의 공백은 %20으로 인코딩됩니다. 둘 다 유효하고, 서버는 양쪽 형식 모두 디코딩합니다. 서버가 망가져서 %20만 처리한다면 이 도구보다 더 큰 문제가 있는 거예요.

입력 JSON 자체는 어떤 형식이어야 하나요?

표준 JSON입니다 — 명세는 json.org나 ECMA-404를 보세요. 키는 문자열, 값은 문자열 또는 (searchParams의 경우) 문자열 배열입니다. 주석 없음. 끝에 쉼표 안 됩니다.

다른 URL & JSON 도구

만드는 건 한 방향이에요. 함께 쓰면 좋은 도구: