URL Encoder/Decoder

What URL encoding does

URL encoding, also called percent-encoding, converts characters that aren't safe to use directly in a URL — spaces, ampersands, question marks, and other reserved or non-ASCII characters — into a percent sign followed by a two-digit hex code, like %20 for a space. URLs can only reliably contain a limited set of characters; anything outside that set needs to be encoded so it doesn't get misread as part of the URL's structure (splitting a query string in the wrong place, for example) or corrupted in transit.

Decoding reverses the process, turning percent-encoded sequences back into their original readable characters.

encodeURI vs. encodeURIComponent

This distinction trips up a lot of developers. encodeURI is meant for encoding a complete URL and leaves characters like /, ?, &, and # untouched, since those are structurally meaningful in a full URL. encodeURIComponent is meant for encoding a single component — like one query parameter's value — and encodes those same characters too, since inside a single value they're just literal characters, not structural ones. Nonkera's tool uses encodeURIComponent behavior, which is almost always the right choice when you're encoding a value that's going into a query string parameter rather than encoding an entire URL at once.

Common use cases

Developers encode query parameter values before appending them to a URL, especially when the value comes from user input and might contain spaces, ampersands, or other special characters that would otherwise break the URL's structure. It's used when constructing API request URLs by hand, when debugging why a URL isn't working as expected (a decoded view often reveals what a percent-encoded sequence actually represents), and when passing data like a search query or a redirect URL as part of another URL's query string.

Tips for working with encoded URLs

If a URL you're debugging looks garbled with lots of % symbols, decoding it here often immediately clarifies what's actually being sent — a common source of confusion is a URL that's been encoded twice, which shows up as literal %25 sequences (the encoded form of a percent sign itself) mixed in with normal text. When building URLs programmatically, encode each parameter value individually with encodeURIComponent-style encoding rather than encoding the whole assembled URL at once, since the latter would incorrectly encode the URL's own structural characters like / and ?.

Why URLs can't contain spaces and special characters directly

The URL specification reserves a specific set of characters for structural purposes — / to separate path segments, ? to start the query string, & to separate parameters, # for fragments — and restricts everything else to a safe subset of ASCII letters, digits, and a handful of punctuation marks. Anything outside that safe set, including spaces, non-English characters, and the reserved characters themselves when they appear inside a value rather than as structure, has to be percent-encoded so a browser or server can parse the URL unambiguously. This is why a search query with spaces in it turns into a URL full of %20 sequences (or sometimes + signs, an older convention used specifically within query strings) once it's actually sent as part of a request.