API Endpoint Builder

You're testing a search endpoint that takes nine query parameters, and three of them have spaces in the values that need URL encoding. Building the URL by hand is one typo away from a 400 response. Plug in the base, add params one at a time, and the encoded URL falls out clean.

Duplicate keys, array params, and nested object syntax are all handled — including the slightly different conventions various frameworks expect (`?a=1&a=2` vs `?a[]=1&a[]=2`). The output is paste-ready for curl, Postman, or your test runner.

If a value contains characters that should be encoded, you'll see the encoded version, not the raw input. Saves the 'why is my request failing' debugging trip.

What's happening underneath is percent-encoding (RFC 3986) applied to anything outside the unreserved set — letters, digits, hyphen, period, underscore, tilde. Spaces become %20 (or + in query strings, depending on the application's convention), ampersands become %26, equals signs become %3D, and so on through the rest. The encoding is what lets you put a search query like 'iced coffee & donuts' into a URL without the ampersand being misread as a parameter delimiter.

A worked example: you want to call `https://api.example.com/search` with three parameters — a query 'red & blue', a category 'home goods', and an array of tags ['summer', 'sale']. The properly encoded URL becomes `https://api.example.com/search?q=red%20%26%20blue&category=home%20goods&tags=summer&tags=sale`. The ampersand inside the query value got encoded as %26 so it doesn't fragment the parameter parsing. The space became %20. The repeated 'tags' key is the standard way to pass arrays in most APIs, though some frameworks expect the bracket notation `tags[]=summer&tags[]=sale` — the API's docs are the only authority on which.

Where you can shoot yourself in the foot: double-encoding. If you take a value that's already encoded ('%20') and run it through encoding again, you get '%2520' — the percent sign itself gets encoded. The receiving server then sees '%20' as a literal, not as a space. This usually happens when intermediate code decodes-then-re-encodes without realizing the input was already encoded. The builder always treats input as raw and encodes once, which is the safe default but can surprise you if you paste already-encoded values.

For OAuth and webhook callbacks the encoding has to be exact — many providers compare the registered redirect URI to the requested one byte-for-byte, including a trailing slash difference, a missing port, or scheme mismatch (http vs https). If your callback fails with 'invalid redirect URI,' the registered string almost certainly differs from what you're sending in some cosmetic way. Print both and diff them.