x-www-form-urlencoded to JSON converter
A local-first developer tool that turns raw form bodies and URL query parameters into structured, readable JSON without requiring an account.
- Accepts
- Form body, query, or full URL
- Repeated keys
- Preserved as arrays
- Browser mode
- Local processing
- Automation
- Versioned JSON API
What problem does it solve?
Form submissions, OAuth callbacks, webhook samples, and copied URLs frequently arrive as dense key-value strings. Reading nested percent escapes and repeated parameters by eye is slow and error-prone.
The converter accepts raw application/x-www-form-urlencoded content, a query string beginning with a question mark, or a complete URL. It applies browser-standard form semantics and returns formatted JSON.
Conversion examples
These examples show details that basic split-on-ampersand snippets commonly mishandle.
Simple form body
name=Fabreco+Studio&active=true{ "name": "Fabreco Studio", "active": "true" }Plus signs are decoded as spaces. Values remain strings because form encoding does not carry JSON types.
Repeated fields
tag=nextjs&tag=typescript&tag=testing{ "tag": ["nextjs", "typescript", "testing"] }Repeated names become arrays so values are not silently overwritten.
Complete URL
https://example.com/callback?code=a%3Db&state=ready#done{ "code": "a=b", "state": "ready" }Only query parameters are converted; percent escapes are decoded and the fragment is ignored.
How parsing works
The converter first normalizes the input: a complete URL contributes its query component, a leading question mark is removed, and raw form content is used directly.
URLSearchParams applies standard form-decoding behavior, including percent escapes, plus-sign spaces, empty values, and equals signs inside values. The converter then groups repeated keys into arrays before serializing formatted JSON.
The browser interface calls a typed pure conversion function and never transmits the input. A separate POST API reuses the same function for automation; API input necessarily reaches the server, is limited to 50,000 characters, and is not persisted.
Known limitations
- Form encoding has no native number, boolean, null, or nested-object types; output values remain strings.
- Bracket conventions such as user[name] or items[] are preserved as key names rather than inferred as nested objects.
- Malformed percent escapes follow the behavior of the browser URL parser and may not match a server framework’s custom decoder.
- A URL without query parameters has nothing to convert.
- The public API is unauthenticated and should not receive secrets when local browser conversion is sufficient.
Common mistakes
Treating plus as a literal plus
In form encoding, a plus sign represents a space. A literal plus should normally be percent encoded as %2B.
Coercing values automatically
The strings “true” and “42” are still strings. Convert types only when your application knows the expected schema.
Overwriting repeated keys
Many quick parsers keep only the last value. This converter preserves every occurrence in an array.
Sending sensitive data to the API
Use the browser converter for credentials, personal data, or private callbacks whenever local processing is required.
FAQ
Questions about form-encoded data
Why are all JSON values strings?
application/x-www-form-urlencoded represents textual key-value pairs and does not include JSON type information. Type coercion would require an external schema.
What happens to repeated keys?
The first value remains a string until another value with the same key appears; repeated values are then represented together as an array.
Can I paste a complete URL?
Yes. The converter extracts its query parameters and ignores the URL path and fragment.
Is there an API?
Yes. The site publishes a versioned POST endpoint, OpenAPI description, health endpoint, and API discovery resources. API requests are processed on the server.