About the URL Builder
Most URL bugs are encoding bugs. A query value containing an ampersand, a plus sign, a space, or a non-ASCII character will silently split a parameter, arrive as a different string, or vanish entirely, and the failure usually surfaces somewhere far from the code that built the URL. This tool assembles the URL and shows exactly what each component looks like after encoding.
The rules differ by position, which is what makes this easy to get wrong by hand. A character that is safe in a path segment may be reserved in a query string, and a plus sign means a literal plus in a path but a space in a form-encoded query. Building the URL structurally, rather than by concatenating strings, removes an entire class of these mistakes.
Nothing is sent anywhere — the URL is assembled in your browser, so you can safely paste query values that contain tokens, identifiers, or customer data.
Frequently asked questions
When do I need to percent-encode a query parameter?
Whenever the value could contain a character with structural meaning: ampersand, equals, question mark, hash, plus, space, or anything non-ASCII. The hash is the one people forget — everything after an unencoded hash is treated as a fragment and never reaches the server at all, so the parameter simply disappears.
Why does my plus sign turn into a space?
Because form encoding and URI encoding disagree. In application/x-www-form-urlencoded content, which is how most servers parse a query string, a plus is decoded as a space. If you want a literal plus in a query value it must be sent as %2B. This is the usual reason a plus-addressed email like [email protected] arrives with a space in it.
What is the difference between encodeURI and encodeURIComponent?
encodeURI is for encoding a whole URL and deliberately leaves the structural characters alone, so it will not touch and or ? or #. encodeURIComponent is for encoding a single value going into a URL and escapes those characters. Using encodeURI on a parameter value is a very common bug — it leaves exactly the characters that break the URL.
Is there a maximum URL length?
Nothing in the HTTP specification, but there are practical ceilings. Browsers and CDNs generally cope to a few thousand characters, and many servers and proxies default to an 8 KB limit on the whole request line and headers combined. If you are approaching that, the request should almost certainly be a POST with a body instead.
Does parameter order matter?
Not to the server in almost all cases — parameters are a set, not a sequence. It matters a great deal to caches. A CDN or browser cache usually keys on the exact URL string, so the same logical request with parameters in two different orders is two cache entries. Emitting parameters in a stable order improves hit rates for free.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.