JSON to URL
URL 부분들을 기술한 JSON 객체를 fetch/curl 호출이 기대하는 URL 문자열로 변환합니다
JSON 설정
URL
JSON to URL은 무슨 일을 하나요?
HTTP 엔드포인트의 부분들 — protocol, host, path, 쿼리 파라미터, hash — 을 기술하는 JSON 객체가 있고, 이걸 fetch(), curl, 또는 HTTP 클라이언트가 그대로 받아먹을 수 있는 한 줄짜리 URL 문자열로 만들어야 하는 상황입니다. 왼쪽에 JSON을 붙여넣으면 오른쪽에 조립되고 퍼센트 인코딩된 URL이 나옵니다. 백엔드 테스트 픽스처, OpenAPI 예제, 설정 파일 — 어디서든 결국 이 변환이 필요합니다.
브라우저 내장 URL 생성자와 URLSearchParams를 써서 URL을 조립하므로, 인코딩 결과는 WHATWG URL 표준이 정의한 그대로이며, 실제 브라우저가 보낼 형태와 동일합니다. 쿼리의 공백은 +, 대괄호는 %5B/%5D, 한글이나 이모지는 UTF-8 퍼센트 인코딩됩니다. 반복되는 쿼리 키는 배열로 전달하면 지원됩니다 — "tag": ["red", "blue"]는 tag=red&tag=blue를 만들어냅니다.
이 페이지가 존재하는 이유는, 대부분의 프로젝트가 이미 어딘가에 URL을 JSON으로 저장해 두기 때문입니다 — 환경 파일, Postman 컬렉션, Cypress 픽스처, OpenAPI 스펙, Helm values. 그 JSON을 스크립트나 일회성 curl을 위해 실제 URL 문자열로 만들어야 할 때, 손으로 짜맞추다 보면 버그가 숨어듭니다. 이 변환은 URL 문법은 RFC 3986을 따르고, 입력은 RFC 8259 표준 JSON을 받습니다. 모든 처리는 로컬에서 — JSON도 URL도 브라우저를 떠나지 않습니다. 반대 방향은 URL to JSON에 있습니다.
JSON을 URL로 변환하는 방법
세 단계. 각 단계가 이 페이지의 버튼에 대응됩니다.
JSON 설정 붙여넣기 또는 샘플 불러오기
URL 부분들을 기술한 JSON 객체를 왼쪽에 떨어뜨리세요. protocol과 host만 필수, 나머지는 모두 선택입니다. 샘플을 누르면 여러 쿼리 파라미터와 hash를 가진 현실적인 이커머스 엔드포인트가 로드됩니다:
{
"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, pathname, searchParams, hash. searchParams 내부에서 문자열은 단일 값, 배열은 반복 키를 의미합니다. JSON 문법은 JSON.parse로 파싱됩니다 — 주석 없음, 후행 콤마 없음.
조립된 URL 확인
오른쪽 패널은 입력하는 동안 갱신됩니다. 전체 URL — https://api.shop.example.com/v1/orders?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2#summary — 이 URL 표준에 정의된 방식으로 각 부분이 퍼센트 인코딩된 형태로 보입니다. 그대로 fetch() 호출, curl 명령, Postman 테스트, 또는 단일 URL 문자열을 기대하는 설정 파일에 넣을 수 있습니다.
복사 또는 다운로드
복사를 누르면 URL이 클립보드로, 다운로드를 누르면 텍스트 파일로 저장됩니다. 새 설정으로 처음부터 시작하려면 입력 패널의 지우기를 사용하세요.
실제로 이걸 쓰게 되는 순간
OpenAPI 예제를 실행 가능한 curl 명령으로 변환
OpenAPI 스펙은 서버를 {url, variables}로, 작업을 parameters가 붙은 path로 기술합니다. 이 조각들로 일회성 curl용 실제 URL을 손으로 만드는 건 번거롭습니다 — path 변수 치환, 쿼리 파라미터 인코딩, 끝의 슬래시 처리. 합쳐진 JSON을 여기 넣고 URL을 복사해서 curl에 붙여넣으세요. 합쳐진 형태는 OpenAPI server-object가 기술하는 것과 동일합니다.
환경 변수 분할로부터 URL 만들기
12-factor 앱은 URL 부분들을 별도 환경 변수로 저장합니다: API_HOST, API_PORT, API_BASE_PATH, API_TOKEN_PARAM. 장애 대응 중 점검 curl을 위해 전체 URL을 만들려면 이걸 조립해야 합니다. JSON 형태로 이 페이지에 붙여넣고 URL을 받아서 실행하세요. bash 스크립트보다 빠르고, +가 들어간 토큰 인코딩을 깜빡할 위험도 없습니다.
URL을 객체로 저장하는 Cypress / Playwright 픽스처
테스트 픽스처는 개별 부분들(예: orderId path 파라미터, page 쿼리 파라미터)을 단언할 수 있도록 요청 URL을 구조화된 형태로 저장하는 경우가 많습니다. 픽스처가 실제 HTTP 호출도 해야 한다면(예: cy.request나 page.goto로 데이터 시드), 구조화된 형태를 다시 문자열로 바꿔야 합니다. JSON to URL은 Marco Rivera가 저장해 둔 픽스처 객체를 테스트 하니스가 호출할 수 있는 URL로 변환합니다.
테넌트별 설정으로 조립되는 Webhook URL
멀티 테넌트 시스템은 고객별로 webhook 설정을 저장합니다: {host: "hooks.tenant-a.example.com", pathname: "/orders/ORD-1001/notify", searchParams: {token: "..."}}. 디스패처는 JSON을 읽고 POST할 URL 문자열이 필요합니다. 이 페이지가 하는 변환과 동일하지만 런타임에 일어날 뿐. 코드가 만들어낼 URL이 고객이 등록한 것과 일치하는지 이 페이지로 확인하세요.
자주 묻는 질문
URL Builder 페이지와 무엇이 다릅니까?
엔진은 같고, 프레이밍이 다릅니다. URL Builder는 자리에 앉아 처음부터 URL을 조립할 때 — 요청을 직접 구성할 때 — 쓰는 페이지입니다. JSON to URL은 JSON이 이미 어딘가에 존재하고(설정, OpenAPI 스펙, 픽스처, 환경 변수 분할 등) 그것을 코드가 기대하는 URL 문자열로 바꿔야 할 때 쓰는 페이지입니다. 지금 하는 일에 맞는 쪽을 고르세요 — 결과 출력은 똑같습니다.
제 JSON은 URL을 다른 형태로 저장합니다 — 아무 모양이나 써도 되나요?
WHATWG URL 부분 이름이 필요합니다: protocol, host, port, username, password, pathname, searchParams(객체), hash. JSON이 다른 키(scheme, baseUrl, query, fragment)를 쓴다면 먼저 이름을 바꾸세요. 이 모양은 new URL(...)이 노출하는 것, URL 스펙이 정의하는 것을 그대로 반영합니다 — fetch와 Node가 내부적으로 사용하는 모델과 같은 모델에 맞추는 셈입니다.
같은 쿼리 파라미터를 두 번 보내려면? (예: ?tag=red&tag=blue)
값으로 배열을 사용하세요: "tag": ["red", "blue"]. 컨버터는 제공한 순서대로 tag=red&tag=blue를 만들어냅니다. 이는 URLSearchParams가 반복 키를 처리하는 방식과 일치하고, 대부분의 서버(Express, Rails, ASP.NET)가 배열 스타일 쿼리 파라미터에 기대하는 형태입니다.
왜 공백이 %20이 아니라 +로 바뀝니까?
쿼리 컴포넌트의 공백은 application/x-www-form-urlencoded 규칙에 따라 +로 인코딩됩니다 — 그게 URLSearchParams가 만들어내는 결과입니다. path의 공백은 %20으로 인코딩됩니다. 둘 다 RFC 3986 기준 유효하고 모든 서버가 양쪽을 디코딩합니다. 서버가 쿼리에서 %20만 받는다면, 그건 서버 쪽 버그입니다.
자격 증명(username/password)을 URL에 포함할 수 있나요?
네 — JSON에 "username"과 "password"를 설정하세요. host 앞에 user:pass@host 형태로 나옵니다. RFC 3986 §3.2.1은 운영 URL에서 이걸 하지 말라고 경고합니다. 브라우저 히스토리, 서버 로그, 프록시 캐시에 남기 때문입니다 — 빠른 로컬 테스트에는 괜찮지만, 공유 설정에는 부적절합니다.
URL이 제 브라우저를 떠나는 일이 있나요?
없습니다. JSON 파싱은 탭 안의 JSON.parse, URL 조립은 탭 안의 new URL(...)이고, 둘 다 서버를 호출하지 않습니다. 업로드도, 로깅도 없습니다. 인터넷에 연결된 상태로 한 번 페이지를 열어두고 연결을 끊은 뒤 캐시에서 계속 사용할 수도 있습니다.
다른 URL & JSON 도구
JSON to URL은 왕복의 절반입니다. 나머지 키트는 여기 있습니다: