JSON

Query String

Wat doet JSON naar Query String?

Je hebt in je code een JSON-config opgebouwd — filterparameters, een analytics-payload, een OAuth-state — en nu moet die achter een URL geplakt worden. Deze pagina doet dat saaie laatste stukje. Plak de JSON links, krijg ?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2&tag=premium&tag=verified rechts terug, klaar om in een link, een fetch-call of een webhook-URL te zetten. Arrays worden uitgevouwen tot herhaalde keys (de conventie die elke moderne server begrijpt), waarden worden netjes percent-encoded en de ? aan het begin zit erbij zodat je direct in een URL kunt plakken.

De omzetting gebruikt de in de browser ingebouwde URLSearchParams — dezelfde primitieve die je server-framework gebruikt om de teruggekomen request te parsen. URLSearchParams produceert volgens de WHATWG URL Standard application/x-www-form-urlencoded-uitvoer, en je JSON wordt geparsed door JSON.parse volgens RFC 8259. Getallen en booleans worden gecoerced naar strings (query-strings hebben geen typesysteem), null- en undefined-waarden worden overgeslagen, en geneste objecten gooien een nette foutmelding zodat je ze kunt platslaan.

Alles draait lokaal in je browser — geen upload, geen serverritje, geen logging. Heb je het omgekeerde probleem (een query-string en je wilt JSON), gebruik dan Query String naar JSON. Wil je de hele URL uit elkaar halen in protocol, host, pad en search-deel, dan zijn de pagina URL naar JSON of de URL-parser beter. De percent-encoding-regels die hier spelen staan in RFC 3986 §2.1, en het bredere URL-parsemodel staat in de MDN URL API-referentie.

JSON omzetten naar een query-string

Drie stappen. Elke stap hoort bij een knop op de pagina.

Plak het JSON-object

Drop de JSON in het linker paneel. De top-level waarde moet een object zijn — arrays en primitieven mappen niet schoon op query-parameters. Klik op Voorbeeld voor een realistische e-commerce filter-payload met een string, een getal, een key tussen rechte haken en een array. Voorbeeld:

{
  "customer": "Ava Chen",
  "status": "active",
  "total[gte]": "49.99",
  "page": 2,
  "tag": ["premium", "verified"]
}

Getallen en booleans worden gecoerced naar strings (query-strings dragen geen types). <code>null</code>- en <code>undefined</code>-waarden worden overgeslagen — anders zouden ze de URL alleen maar volstoppen.

Lees de query-string

Het rechter paneel werkt mee terwijl je typt. Het voorbeeld hierboven produceert ?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2&tag=premium&tag=verified. Spaties worden + (form-encoded stijl — zie de FAQ), rechte haken worden %5B/%5D, en de tag-array vouwt uit naar twee aparte tag=-parameters.

Kopieer of download

Klik op Kopiëren om de query-string naar je klembord te sturen, of op Downloaden om hem als querystring.txt te bewaren. Wissen reset het invoerpaneel.

Wanneer je dit echt zou gebruiken

Deelbare filter-URLs bouwen

In je dashboard kan een gebruiker bestellingen filteren op klant, status en datumbereik. De state leeft als JSON-object in je component ({customer: "Marco Rivera", status: "active", date_from: "2026-04-01"}). Om de view deelbaar te maken hang je dat aan de URL — plak de JSON hier, kopieer de query-string en klaar. Geldt net zo goed voor categorie-pagina's in een webshop, zoekresultaten, alles met stateful filters.

Webhook-callback-URLs in elkaar zetten

Stripe, GitHub en de meeste webhook-zenders laten je metadata in de query-string van de callback-URL stoppen. Je hebt een JSON-object dat de gebruiker beschrijft ({userId: "USR-1001", source: "checkout", flow: "onboarding"}) en moet dat aan https://api.example.com/webhook?... hangen. Plakken, kopiëren, plakken — veel beter dan elke waarde met de hand URL-encoden en je afvragen welke tekens je moet escapen.

OAuth- en OpenID-URLs genereren

OAuth-authorize-URLs zijn 8 tot 12 query-parameters: client_id, redirect_uri, scope, state, response_type, enzovoort. Eerst in JSON opbouwen (om het netjes te zien) en hier converteren is sneller dan strings aan elkaar plakken en hopen dat de encoding klopt. De state-parameter draagt vaak een nonce en een return-pad mee die zelf weer escaping nodig hebben.

API-requests bouwen in HTTP-clients

Als je een API-endpoint test in cURL, Postman of een snelle fetch(), heb je de parameters meestal als JSON-snippet uit de documentatie. Hier converteren, aan de URL plakken, request afvuren. De productfilter voor bestelling ORD-1001 {"sku": "SKU-101", "include": "variants"} wordt in één plakbeurt ?sku=SKU-101&include=variants.

Veelgestelde vragen

Waarom worden spaties als + gecodeerd in plaats van %20?

Omdat de uitvoer form-encoded is (application/x-www-form-urlencoded) — dat is wat elke browser stuurt en wat elke server in een query-string verwacht. Technisch gezien geeft RFC 3986 in URI-componenten de voorkeur aan %20, maar de form-encoded conventie met + voor spaties is ouder dan RFC 3986 en wordt door query-strings al sinds de jaren 90 gebruikt. Elk modern serverframework decodeert allebei — Express, FastAPI, ASP.NET, Spring, Rails, Django, noem maar op. Heb je echt %20 nodig, draai dan even .replace(/\+/g, "%20") over de uitvoer.

Hoe worden arrays gecodeerd?

Ze worden uitgevouwen tot herhaalde keys. {"tag": ["premium", "verified"]} wordt tag=premium&tag=verified. Dat is de conventie die URLSearchParams produceert, en die maakt aan de ontvangende kant een schone round-trip via URLSearchParams.getAll(). Als je server bracket-notatie verwacht (tag[]=premium&tag[]=verified — gangbaar in PHP en Rails), noem dan je JSON-key tag[] in plaats van tag.

Mag ik geneste objecten in de JSON hebben?

Nee — query-strings zijn van nature plat. De pagina geeft een nette foutmelding zodra ze een genest object ziet, zodat je het kunt platslaan. De gebruikelijkste workaround zijn keys met bracket-notatie: in plaats van {"filter": {"status": "active"}} schrijf je {"filter[status]": "active"}. Frameworks als Rails, PHP en qs.js parsen dat aan de serverkant terug naar geneste objecten. Of sla het gewoon conceptueel plat: {"status": "active"} als er geen echte ambiguïteit is.

Wat gebeurt er met null- en undefined-waarden?

Ze worden overgeslagen. {"customer": "Ava Chen", "status": null} levert ?customer=Ava+Chen op, niet ?customer=Ava+Chen&status=. De redenering: status= in de URL betekent "lege string", dat is een echte waarde en wat anders dan "geen status". null als leeg sturen zou informatie verliezen en verwarrend zijn. Wil je echt status=, stuur dan {"status": ""}.

Blijven nummers en booleans als type behouden?

Nee — query-strings dragen alleen strings. {"page": 2} wordt page=2, en {"debug": true} wordt debug=true. Je server-side code moet het schema kennen en ze terugconverteren. Dat is fundamenteel voor query-strings (en form-data) — het wire-formaat ziet geen verschil tussen het getal 2 en de string "2". Heb je getypeerde parameters nodig, stuur ze dan in de request-body als JSON.

Hoe gaat het om met Unicode en emoji in keys of waarden?

Soepel. URLSearchParams codeert de bytes als UTF-8 en percent-escapet alles buiten de veilige set. Dus {"name": "中文"} wordt name=%E4%B8%AD%E6%96%87, en {"reaction": "🔥"} wordt reaction=%F0%9F%94%A5. Aan de ontvangende kant decodeert URLSearchParams (of de query-parser van welk framework dan ook) het meteen terug. Er is geen encoding-instelling om aan te draaien — UTF-8 is wat de URL-Standard voorschrijft.

Waar is dat voorop staande vraagteken voor?

Zodat je de uitvoer direct aan een URL kunt plakken — https://shop.example.com/orders + ?customer=Ava+Chen&page=2 = werkende URL. Hang je het achter een URL die al een query-string heeft, laat dan de ? weg en gebruik &. Is je invoer leeg of {}, dan is de uitvoer ook leeg (geen losse ?).

Andere URL- en JSON-tools

Een query-string bouwen is één bewerking. Dit combineert er goed mee: