URL Encoder & Decoder — Free Online Tool

encodeURIComponent is for values, not whole URLs

This tool uses encodeURIComponent, which is built for encoding a single piece of data that will be dropped into a URL — a query parameter value, a form field, a fragment. That is the only mode it offers, and it is the right one for the overwhelmingly common case.

The distinction matters because the two standard functions differ in exactly one way: which characters they consider structural and therefore leave alone. encodeURIComponent assumes it is handling a value, so it encodes nearly everything, leaving only letters, digits and - _ . ! ~ * ' ( ) untouched. A space becomes %20, an ampersand %26, an equals sign %3D, a slash %2F. The related encodeURI assumes it is handling a whole URL and deliberately preserves the reserved characters that give a URL its shape — which is why it is the wrong choice for a value.

Using the wrong one breaks parameter boundaries

Take the search term cats & dogs. Encoded properly it becomes cats%20%26%20dogs, and the receiving server reads the ampersand as part of the value because it is no longer a literal &.

Leave that ampersand unencoded — which is what happens if you reach for encodeURI, or skip encoding entirely — and the server sees q=cats & dogs as two parameters: q=cats and dogs=. Your search silently becomes "cats". No error is raised anywhere; the value is simply truncated at the first ampersand, and the same applies to any value containing =, ? or #. This is the single most common URL-handling bug there is.

The mirror-image mistake is running encodeURIComponent over a complete URL, which turns https://example.com/a into https%3A%2F%2Fexample.com%2Fa — correct as a value to be passed along, but no longer a usable address if you meant it as one.

Watch for double encoding

A percent sign is itself encoded, to %25. So encoding an already-encoded string turns %20 into %2520, and the tell-tale is seeing %25 followed by two more hex digits.

In practice this almost always means a value was encoded once in application code and again by a framework, HTTP client or template that also encodes. Decoding twice fixes the symptom, but the value will break again next time — the actual fix is finding which layer is encoding redundantly and removing one of them.

The plus sign, and non-ASCII characters

The plus sign is a genuine trap. In a query string it traditionally means a space, a legacy convention from HTML form submission, but percent-decoding alone does not convert it, and encodeURIComponent encodes a literal plus as %2B. So a value that genuinely contains a plus — a phone number in international format is the usual casualty — comes out differently depending on which layer decodes it, and can arrive as a space at the far end.

Non-ASCII characters are encoded as their UTF-8 bytes, which is why one character can become several escapes: é becomes %C3%A9, and characters outside the Latin range become three or four escapes each. That is correct behaviour, not corruption — it is why a percent-encoded string is often much longer than the text it represents.

Once you have the values encoded, Query String to JSON will parse a full query string back into structured data.