URL Encoder & Decoder

What URL encoding is

A URL can only contain a small set of ASCII characters: unaccented letters, digits, and a handful of symbols. On top of that, some of those symbols carry meaning: / separates path segments, ? starts the query string, & separates parameters, = joins a name to its value, and # introduces the fragment. To include any other character — or to use one of those symbols as data rather than as a delimiter — you use percent-encoding, defined in RFC 3986.

The rule is simple: the character is converted to bytes using UTF-8, and each byte is written as % followed by its two-digit hexadecimal value. A space is byte 0x20, so it becomes %20; ñ takes two bytes in UTF-8 (0xC3 0xB1) and becomes %C3%B1; the € sign takes three and ends up as %E2%82%AC.

The three modes and when to use each

The key question before encoding is which part of the URL you're building, because that determines which characters need protecting:

• Component (encodeURIComponent): for a single value that will go inside a URL, such as a parameter value (?q=…) or one path segment. It also encodes / ? & = #, because inside a value those characters are data and must not be mistaken for delimiters. This is the right mode in the vast majority of cases.
• Full URL (encodeURI): for an entire URL whose structure is already in place and that just contains a stray space or accented letter. It leaves every delimiter alone, so it should never be used on a value: if the value contains &, the result splits the parameter in two.
• Form (application/x-www-form-urlencoded): the format browsers use to submit HTML forms, and what URLSearchParams produces. It's nearly identical to component mode, but turns spaces into + and also encodes ! ' ( ) ~.

Reference table

How each common character comes out in each mode:

Two rows deserve a closer look. A literal + inside a value must always be encoded as %2B, because on the server side many libraries read + in a query string as a space. And % itself encodes to %25 — the telltale sign of double encoding, where an already-encoded value gets encoded again and %20 turns into %2520.

Decoding and catching errors

When decoding, the tool turns each %XX sequence back into its byte and reassembles the UTF-8 characters. In form mode it also reads + as a space. If it finds a % not followed by two hex digits (an unencoded 100%, say), or a run of bytes that doesn't form a valid UTF-8 character (an ñ missing its second byte), it reports the exact sequence and its position — instead of JavaScript's generic URIError: URI malformed.

Parsing a URL

The second part of the tool breaks an absolute URL into its components (protocol, username, host, port, path, and fragment) and lists the query string parameters already decoded, in their original order and keeping duplicates. It uses the same URL API browsers do, so the result is exactly what a web application would see. It's handy for inspecting long links stuffed with tracking parameters, debugging login redirects, or figuring out what a server actually receives.

Common mistakes

• Building URLs by string concatenation. "https://api.example.com/search?q=" + "salt & pepper" produces a URL where the server receives q=salt plus an empty parameter named pepper. Encode the value in component mode — or better, build the URL with URL and URLSearchParams.
• Using encodeURI on a parameter. It doesn't encode & or =, so it has the same problem as concatenation.
• Encoding twice. If a value already went through an encoder, running it again turns every % into %25.
• Mixing up + and %20. Both mean a space in a form-style query string, but in a URL's path, + is a literal plus sign.

Each case is covered in detail, with examples in several languages, in URL Encoding Explained: Percent-Encoding, %20, and +.

Privacy

Encoding, decoding, and URL parsing all happen in your browser. Nothing you type is sent to a server or saved in this page's URL.