JSON

Query String

Vad gör JSON till Query String?

Du har byggt en JSON-konfiguration i koden — filterparametrar, en analytics-payload, en OAuth-state — och nu ska den hängas på en URL. Den här sidan tar hand om den där tråkiga sista biten. Klistra in JSON till vänster och få ?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2&tag=premium&tag=verified till höger, redo att slängas in i en länk, ett fetch-anrop eller en webhook-URL. Arrayer expanderas till upprepade nycklar (konventionen som varje modern server förstår), värdena percent-kodas korrekt och det inledande ? finns med så att du kan klistra in direkt i en URL.

Konverteringen använder webbläsarens inbyggda URLSearchParams — samma primitiv som ditt server-ramverk använder för att parsa det inkommande anropet. URLSearchParams producerar application/x-www-form-urlencoded-utdata enligt WHATWG URL Standard, och din JSON parsas av JSON.parse i enlighet med RFC 8259. Tal och booleans gjuts om till strängar (query-strängar har inget typsystem), null- och undefined-värden hoppas över, och nästade objekt kastar ett tydligt fel så att du kan platta till dem.

Allt körs lokalt i webbläsaren — ingen uppladdning, inget serverhopp, ingen loggning. Har du motsatt problem (en query-sträng och vill ha JSON), använd Query String till JSON. Vill du dela upp hela URL:en i protokoll, host, sökväg och search-del passar sidan URL till JSON eller URL Parser bättre. Reglerna för percent-kodning som används här är definierade i RFC 3986 §2.1, och den bredare URL-parsemodellen finns dokumenterad i referensen för MDN URL API.

Så konverterar du JSON till en query-sträng

Tre steg. Varje steg motsvarar en knapp på sidan.

Klistra in JSON-objektet

Släpp ned JSON i vänstra panelen. Värdet på toppnivå måste vara ett objekt — arrayer och primitiver mappar inte rent på query-parametrar. Klicka på Exempel för en realistisk e-handels-filter-payload med en sträng, ett tal, en nyckel inom hakparenteser och en array. Exempel:

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

Tal och booleans gjuts om till strängar (query-strängar bär inga typer). <code>null</code>- och <code>undefined</code>-värden hoppas över — annars skulle de bara skräpa ner URL:en.

Läs query-strängen

Den högra panelen uppdateras medan du skriver. Exemplet ovan ger ?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2&tag=premium&tag=verified. Mellanslag blir + (form-encoded-stil — se FAQ), hakparenteser blir %5B/%5D, och tag-arrayen expanderas till två separata tag=-parametrar.

Kopiera eller ladda ner

Klicka på Kopiera för att skicka query-strängen till urklippet, eller på Ladda ner för att spara den som querystring.txt. Rensa nollställer indatapanelen.

När du faktiskt skulle använda det här

Bygga delbara filter-URL:er

Din dashboard låter användaren filtrera ordrar på kund, status och datumintervall. Tillståndet bor som ett JSON-objekt i komponenten ({customer: "Marco Rivera", status: "active", date_from: "2026-04-01"}). För att vyn ska gå att dela hänger du på det i URL:en — klistra in JSON här, kopiera query-strängen, klart. Samma sak gäller kategorisidor i e-handel, sökresultat, allt med filter som har tillstånd.

Koppla webhook-callback-URL:er

Stripe, GitHub och de flesta webhook-avsändare låter dig lägga metadata i query-strängen på callback-URL:en. Du har ett JSON-objekt som beskriver användaren ({userId: "USR-1001", source: "checkout", flow: "onboarding"}) och behöver hänga på det till https://api.example.com/webhook?.... Klistra, kopiera, klistra — mycket bättre än att URL-koda varje värde för hand och fundera på vilka tecken som måste escapas.

Generera OAuth- och OpenID-URL:er

OAuth-authorize-URL:er har 8–12 query-parametrar: client_id, redirect_uri, scope, state, response_type osv. Att bygga en i JSON först (för att se den rent) och konvertera här är snabbare än att kedja ihop strängar och hoppas att kodningen blev rätt. state-parametern bär ofta en nonce och en return-path som behöver egen escaping.

Bygga API-anrop i HTTP-klienter

När du testar en API-endpoint i cURL, Postman eller ett snabbt fetch() har du oftast parametrarna som ett JSON-utdrag från dokumentationen. Konvertera här, häng på URL:en, skjut iväg anropet. Produktfiltret för order ORD-1001 {"sku": "SKU-101", "include": "variants"} blir ?sku=SKU-101&include=variants i en enda inklistring.

Vanliga frågor

Varför kodas mellanslag som + i stället för %20?

För att utdatan är form-encoded (application/x-www-form-urlencoded) — det varje webbläsare skickar och varje server förväntar sig i en query-sträng. RFC 3986 föredrar tekniskt %20 i URI-komponenter, men form-encoded-konventionen med + för mellanslag är äldre än RFC 3986 och är vad query-strängar har använt sedan 90-talet. Alla moderna server-ramverk avkodar bägge — Express, FastAPI, ASP.NET, Spring, Rails, Django, vad du vill. Om du absolut behöver %20, kör en snabb .replace(/\+/g, "%20") på utdatan.

Hur kodas arrayer?

De expanderas till upprepade nycklar. {"tag": ["premium", "verified"]} blir tag=premium&tag=verified. Det är konventionen URLSearchParams producerar, och den round-trippar rent via URLSearchParams.getAll() på mottagarsidan. Om din server förväntar sig hakparentes-notation (tag[]=premium&tag[]=verified — vanligt i PHP och Rails), namnge JSON-nyckeln tag[] i stället för tag.

Kan jag ha nästade objekt i JSON:en?

Nej — query-strängar är platta från början. Sidan returnerar ett tydligt fel om den ser ett nästat objekt så att du kan platta till det. Den vanligaste lösningen är hakparentes-nycklar: i stället för {"filter": {"status": "active"}}, skriv {"filter[status]": "active"}. Ramverk som Rails, PHP och qs.js parsar tillbaka det till nästade objekt på serversidan. Eller platta till det rent konceptuellt: {"status": "active"} om det inte finns någon riktig tvetydighet.

Vad händer med null- och undefined-värden?

De hoppas över. {"customer": "Ava Chen", "status": null} ger ?customer=Ava+Chen, inte ?customer=Ava+Chen&status=. Resonemanget: status= i URL:en betyder "tom sträng", vilket är ett riktigt värde och något annat än "ingen status". Att skicka null som tom skulle vara förlustfyllt och förvirrande. Vill du på riktigt ha status=, skicka {"status": ""}.

Behåller tal och booleans sina typer?

Nej — query-strängar bär bara strängar. {"page": 2} blir page=2, och {"debug": true} blir debug=true. Din server-kod måste känna till schemat och konvertera tillbaka. Det är inbyggt i query-strängar (och formulärdata) — wire-formatet vet inte skillnaden mellan talet 2 och strängen "2". Behöver du typade parametrar, skicka dem i request-bodyn som JSON.

Hur hanterar den Unicode och emoji i nycklar eller värden?

Snyggt. URLSearchParams kodar bytena som UTF-8 och percent-escapar allt utanför den säkra mängden. Så {"name": "中文"} blir name=%E4%B8%AD%E6%96%87, och {"reaction": "🔥"} blir reaction=%F0%9F%94%A5. På mottagarsidan avkodar URLSearchParams (eller vilken query-parser ramverket nu har) tillbaka det. Det finns ingen kodningsinställning att meka med — UTF-8 är vad URL-standarden föreskriver.

Vad är det inledande frågetecknet till för?

För att du ska kunna klistra utdatan direkt på en URL — https://shop.example.com/orders + ?customer=Ava+Chen&page=2 = en fungerande URL. Hänger du på en URL som redan har en query-sträng, skippa ? och använd &. Om indata är tom eller {} är utdata också tom (inget ensamt ?).

Andra URL- och JSON-verktyg

Att bygga en query-sträng är en operation. Det här passar bra ihop med det: