URL Encoder / Decoder

"URL encode" is three different operations with one name, and choosing the wrong one is the usual reason a callback URL arrives broken at the server. This page applies whichever of the three you select, in the browser, with the built-in functions encodeURI, encodeURIComponent and the form rules that browsers use for application/x-www-form-urlencoded. No request is made. The sections below explain where the three rules actually differ, because the difference is not cosmetic.

The reserved set is the entire difference

The RFC that defines percent-encoding lists a set of reserved characters — :/?#[]@!$&'()*+,;= — which carry structural meaning. encodeURI deliberately leaves those alone, because it assumes you are handing it a complete URL and do not want the scheme, host or path separators destroyed. encodeURIComponent escapes them all, because it assumes you are handing it one value that will be dropped into a slot and must not be able to change the surrounding structure. So the same text encodes differently depending on which function you call, and that is the point: encodeURIComponent('a/b?c=d') becomes a%2Fb%3Fc%3Dd, while encodeURI('a/b?c=d') is unchanged.

The practical consequence is a rule of thumb worth memorising: encode a value with encodeURIComponent, and encode a whole URL only when you are logging or displaying it. If you pass a query value to encodeURI, its & and = survive, and the server parses one value as several parameters.

Space is + or %20, and the choice follows the content type

In a path segment or a query value, a space is %20. In an HTML form submission with the content type application/x-www-form-urlencoded, a space is +, a convention inherited from the earliest web servers. The two are not interchangeable in both directions: a literal plus sign in a path segment is just a plus, but the same plus in a form body means a space. That is why decoding a path with the form rule can invent spaces that were never there, and why the two rules are separate options here rather than one "URL decode".

The form rule differs in a second, less obvious way. The URL standard's form percent-encode set is the component set plus !, ', (, ) and ~, so a form body escapes all five of those while encodeURIComponent leaves them alone. That means the output of encodeURIComponent is not a valid form body for any value containing a tilde or a parenthesis. If you are building a body for a POST, select the form rule.

Double encoding, and why you only notice it in a redirect

Double encoding is the most expensive of these mistakes because it fails quietly. A slash encoded once is %2F; encoded again, the percent sign of that sequence becomes %25 and the string becomes %252F. The receiving server decodes once and is left holding a literal %2F where it expected a path separator, so a route never matches and the user lands on a 404 with a URL that looks almost right. OAuth redirect_uri values and pre-signed storage URLs are the two places this bites hardest, because both are encoded by the client, then embedded in another URL by a library, and it is easy to encode at both layers.

The signature to look for is %25 in a string that was supposed to be encoded exactly once. As you type, this page flags the sequences it recognises — an existing percent escape, a %25, an ambiguous plus, a raw space, a fragment — so you can see the mistake before it becomes a redirect. The one hard rule is to encode once, at the boundary where the value enters the URL, and never to encode an already-encoded string.

What you must not encode, and what must be encoded once

Do not run the scheme and host through encodeURIComponent. Doing so turns https://example.com into https%3A%2F%2Fexample.com, which is not a URL any client will follow. Build the URL structurally, then encode only the parts that are data. The path is a grey area: each segment is a value and may be encoded, but the slashes between segments must stay literal — which is exactly why you encode segments individually with the component rule rather than encoding the whole path at once. And remember that a fragment, everything after #, never reaches the server at all, so encoding it has no effect on the request no matter which rule you use.

How to verify that nothing is uploaded

Clear the network panel in your developer tools, then encode a signed URL here. Nothing carries the URL to a server. Disconnect from the network and try again: the tool still works, because there is no backend to talk to. The only third-party script is the ad tag, which cannot read the workbench. The privacy policy lists every script the page loads.

Which rule should I pick for a query string value?

Component, which is encodeURIComponent. A single query value must not be able to inject its own &, = or #, and only encodeURIComponent escapes those. If you use the full-URL rule on a value that contains an ampersand, the ampersand survives and the server sees an extra parameter.

Why did my link turn into %252F after a redirect?

That is double encoding. The value was already encoded once, then the whole URL was encoded again, so the percent sign of %2F became %25 and the string became %252F. When the receiving server decodes once it is left with a literal %2F instead of a slash. Encode exactly once, at the boundary where the value is inserted.

Should a space be %20 or +?

It depends on where the string is going. In a path segment or a query value a space is %20. In an application/x-www-form-urlencoded body — which includes most HTML form posts — a space is +. The two lose information if you guess wrong: decoding a path with the form rule turns a literal plus into a space, and decoding a form body with the strict rule leaves the plus signs in place.

Does this tool send my URLs anywhere?

No. Encoding and decoding are string operations done by the page, with no request and no logging. That matters because URLs frequently carry API keys, signed tokens and personal data in their query strings. You can confirm it in the network panel or by using the tool while offline.