쿼리 문자열

JSON

쿼리 문자열을 JSON으로는 어떤 일을 하나요?

왼쪽에 쿼리 문자열을 붙여 넣으면 — 앞의 ?가 있어도 없어도 됩니다 — 오른쪽에 JSON 객체가 채워집니다. 값은 도중에 URL 디코딩되며(따라서 customer=Ava%20Chen은 "customer": "Ava Chen"이 됩니다), 같은 키가 여러 번 등장하면 JSON 배열로 합쳐집니다. 마지막 부분은 즉흥적인 문자열 분리로는 대부분 잘못 처리하는 부분이고, 이 페이지가 존재하는 이유이기도 합니다.

파싱에는 브라우저 내장 URLSearchParams를 사용합니다. 모든 최신 웹 프레임워크에서 request.query를 떠받치는 그 녀석입니다. URLSearchParams는 WHATWG URL 표준의 application/x-www-form-urlencoded 규칙을 따릅니다. 폼이 POST할 때 브라우저가 보내는 형식과 같습니다. 출력은 이후 JSON.stringify를 통해 RFC 8259에 따라 직렬화됩니다.

모든 처리는 브라우저에서 실행됩니다. 입력이 전체 URL이라도 페이지는 너그럽게 받아들여 쿼리 부분만 뽑아냅니다. URL 컴포넌트(호스트, 경로 등) 자체가 필요하다면 대신 URL to JSON을 사용하세요. JSON을 보관하지 않고 파라미터만 보고 싶다면 URL Parser 페이지가 더 적합합니다. 여기서 작동하는 퍼센트 인코딩 규칙은 RFC 3986 §2.1에 정의되어 있습니다.

쿼리 문자열을 JSON으로 변환하는 방법

세 단계. 각 단계는 이 페이지의 버튼과 1대1로 대응합니다.

쿼리 문자열 붙여 넣기

왼쪽 패널에 쿼리 문자열을 넣습니다. 앞의 ?가 있어도 괜찮습니다 — 파서가 떼어냅니다. 샘플을 클릭하면 퍼센트 인코딩된 값, 대괄호 표기, 반복되는 tag 키가 들어 있는 현실적인 이커머스 필터 URL이 로드됩니다. 샘플:

?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2&tag=premium&tag=verified

<code>https://shop.example.com/orders?...</code> 같은 전체 URL을 붙여 넣어도 됩니다. 페이지가 쿼리 부분을 알아서 뽑아냅니다.

JSON 객체 읽기

입력하는 즉시 오른쪽 패널이 갱신됩니다. 각 파라미터가 키, 각 값은 디코딩되며, 반복되는 키는 배열이 됩니다. 그래서 위 샘플은 "customer": "Ava Chen", "total[gte]": "49.99", "tag": ["premium", "verified"]를 만들어 냅니다. 숫자도 문자열로 유지됩니다 — 쿼리 문자열에는 타입 정보가 없기 때문에 흉내 내봐야 버그를 숨기는 결과가 됩니다.

복사, 다운로드, 압축

복사로 JSON을 클립보드에 보내고, 다운로드로 querystring.json으로 저장하고, 압축으로 한 줄로 만듭니다. 지우기는 입력 패널을 초기화합니다.

실제로 쓰게 되는 상황

요청 로그 디버깅

서버 로그는 요청 라인을 그대로 남기며, 쿼리 문자열도 통째로 적힙니다. 어떤 고객의 검색이 왜 빈 결과를 냈는지 추적할 때, 로그에서 ?customer=Marco%20Rivera&status=cancelled&date_from=2026-04-01&date_to=2026-04-30을 이 페이지에 복사하는 편이 머릿속에서 각 값을 URL 디코딩하는 것보다 빠릅니다. JSON으로 만들면 실제 필터 값이 한눈에 보입니다.

실제 트래픽으로 테스트 픽스처 만들기

쿼리 파라미터 12개를 받는 엔드포인트의 테스트를 작성한다고 합시다. 운영에서 실제 URL을 가져와 쿼리 문자열을 여기에 붙여 넣고, 결과 JSON을 테스트의 파라미터 객체로 사용합니다. 진짜 이름, 진짜 형태, 진짜로 잡히는 버그 — 머릿속에서 customer: "ORD-1001"을 만들어 내는 것보다 훨씬 낫습니다.

쿼리 문자열 규약 간 마이그레이션

스택마다 배열을 인코딩하는 방식이 다릅니다 — ?tag=red&tag=blue, ?tag[]=red&tag[]=blue, ?tag=red,blue. 먼저 JSON으로 변환하면 중립적인 중간 형식이 생깁니다. 거기서부터 목표 규약으로 옮기는 일은 정규식 고고학이 아니라 5줄짜리 스크립트가 됩니다.

OAuth, 웹훅, 분석 콜백

OAuth 콜백은 ?code=abc&state=xyz로 돌아옵니다. Stripe나 GitHub 같은 서비스의 웹훅 URL은 메타데이터를 쿼리 문자열에 욱여넣습니다. 분석용 리다이렉트는 그 위에 UTM과 트래킹 파라미터를 한 다스씩 쌓습니다. 쿼리 부분만 여기 붙여 넣으면 호스트를 먼저 떼어낼 필요 없이 파라미터 객체로 바로 갈 수 있습니다.

자주 묻는 질문

앞의 물음표를 꼭 포함해야 하나요?

아니요 — 있든 없든 붙여 넣으세요. 파서는 앞의 ?가 보이면 떼어냅니다. https://api.shop.example.com/orders?customer=Ava%20Chen 같은 전체 URL을 붙여 넣어도 페이지가 쿼리 부분을 뽑아냅니다.

반복되는 키는 어떻게 처리되나요?

JSON 배열로 합쳐집니다. 따라서 ?tag=premium&tag=verified는 "tag": ["premium", "verified"]가 됩니다. 이는 URLSearchParams.getAll()의 동작, 그리고 Express, FastAPI, ASP.NET, Spring이 쿼리 문자열을 파싱하는 방식과 일치합니다.

?debug나 ?dry-run처럼 값이 없는 키는 어떻게 되나요?

빈 문자열이 됩니다 — "debug": "". URLSearchParams는 WHATWG URL 표준에 따라 =가 없는 키를 key=와 동일하게 취급합니다. 진짜 불리언이 필요하면 obj.debug = "debug" in obj 같은 식으로 JSON을 후처리하세요.

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

대괄호는 키의 일부로 그대로 유지됩니다 — 출력에는 "items[]": ["1", "2"]가 표시됩니다. 와이어 위의 바이트에 충실한 결과입니다. 프레임워크(PHP, Rails, qs.js)가 대괄호를 떼거나 중첩 객체로 풀어야 한다면 후처리 단계로 처리하세요.

숫자나 불리언처럼 보여도 왜 모든 값이 문자열인가요?

쿼리 문자열에는 타입 정보가 없기 때문입니다. ?count=5도 ?count=true도 그저 텍스트일 뿐입니다. 숫자나 불리언으로 자동 변환하면 해피 패스 샘플에서는 깔끔해 보이지만, 고객 이름이 "1"이거나 누군가 ?id=007이라고 적는 순간 조용한 버그가 생깁니다. 출력은 문자열로 두고, 스키마를 알고 있는 코드에서 변환하세요.

유니코드와 이모지는 어떻게 처리되나요?

깔끔하게 처리됩니다. URLSearchParams는 바이트를 퍼센트 디코딩한 다음 UTF-8로 해석합니다 — 그래서 ?name=%E4%B8%AD%E6%96%87은 "name": "中文"이 되고, ?reaction=%F0%9F%94%A5 같은 이모지는 "reaction": "🔥"가 됩니다. 그다음 JSON.stringify가 RFC 8259 §7에 따라 이스케이프가 필요한 것을 이스케이프합니다.

다른 URL & JSON 도구

쿼리 문자열 디코딩은 한 가지 작업입니다. 함께 쓰면 좋은 도구들: