URL Encoder / Decoder

Fixing Broken Requests Caused by Encoding

When an HTTP request fails in a way that looks encoding-related — a 400 response, a truncated query parameter, or a redirect landing on the wrong URL — work through the failure in a fixed order. First, check for double encoding: a value that was already percent-encoded once (by a frontend framework, for instance) and then encoded again by a proxy or gateway turns %20 into %2520, which decodes back to a literal %20 string instead of a space. Paste the suspect value into this tool's decode mode twice in a row — if the second decode still changes the text, double encoding is the cause. Second, check for a reserved character left unencoded in a place it shouldn't be — an unencoded & or = inside what should be a single parameter value gets misread as a new parameter boundary, silently truncating or corrupting the intended value.

Third, if a value contains a literal + that's arriving at the server as a space (or vice versa), you're looking at the classic form-encoding versus path-encoding mismatch — the fix is almost always to standardize on %20 and stop relying on + outside form submissions. Finally, if international or emoji characters are getting mangled, confirm the encoding step is running on the UTF-8 byte sequence rather than an intermediate representation — encodeURIComponent handles this correctly by default in JavaScript, but hand-rolled encoding logic in other languages sometimes doesn't.

curl, jq, and the Command Line Equivalents

Every encode/decode operation this tool performs has a direct command-line equivalent, and knowing both means you can move fluidly between a quick browser check and a scripted pipeline. curl --data-urlencode "q=hello world" encodes a form value automatically before sending it, sparing you from manually encoding query parameters in ad hoc curl commands. In Python, urllib.parse.quote() mirrors encodeURIComponent's behavior (with quote_plus() available for the form-encoded, space-as-plus variant), while urllib.parse.unquote() reverses it. If you're processing JSON with jq, the @uri format string percent-encodes a string value inline — echo '"hello world"' | jq -r '@uri' — useful when building URLs inside a shell pipeline without reaching for a full scripting language. This browser tool is the faster path for a single one-off check; the command-line equivalents are what you'd actually put in a script, a Makefile target, or a CI step that needs to encode values programmatically rather than by hand.

Turning a Messy Query Into a Safe One

Suppose you're building a search endpoint and need to pass the raw query status: active & region=eu as a single parameter value. Typed directly into a URL, the colon, ampersand, space, and equals sign would each be misinterpreted — the & in particular would be read as starting a second parameter. Running it through encodeURIComponent produces status%3A%20active%20%26%20region%3Deu — every character with special meaning is converted to its percent-encoded form, leaving only letters and the safe unreserved characters untouched. That encoded string can now be appended safely as ?q=status%3A%20active%20%26%20region%3Deu, and the server will decode it back to the exact original text before parsing it as a single value. Running the encoded string back through the tool's decode mode confirms the round trip: the output matches the original input exactly, character for character — the check worth doing before shipping any encoding logic you didn't write yourself.

Percent-Encoding, Defined

URLs are restricted to a limited set of ASCII characters by the underlying specification (RFC 3986); anything outside that set — spaces, most punctuation, and every non-ASCII character — has to be represented instead as a percent sign followed by the character's hexadecimal byte value, so a space becomes %20 and an ampersand becomes %26. This matters to DevOps engineers constantly: query string parameters built from user input, redirect targets containing dynamic paths, webhook payloads carrying URL-encoded form data, and CDN or reverse-proxy rewrite rules all depend on correct percent-encoding to avoid the request being parsed incorrectly somewhere along the chain. Getting it wrong doesn't usually produce a clean error — it produces a request that "mostly works" until it hits a value containing exactly the wrong character, which is why encoding bugs tend to surface intermittently rather than immediately during initial testing.

Frequently Asked Questions