URL Encoder and Decoder

Component or full URL — the distinction that matters

Getting this wrong is the source of most URL encoding bugs, and the two modes exist because they encode different character sets.

Component encoding escapes everything that is not an unreserved character, including /, ?, &, = and :. Use it for a single value being placed into a URL — a search term, a redirect target, a filename. In JavaScript this is encodeURIComponent().

Full-URL encoding leaves the structural characters alone, because they are doing their job as separators, and escapes only spaces, non-ASCII characters and a few others. Use it on a complete URL you want to tidy. In JavaScript this is encodeURI().

The classic bug: taking a redirect URL and encoding it with full-URL mode. The ? and & survive unescaped, so when the whole thing is placed into another URL's query string, the receiving server reads your redirect target's parameters as its own. The result is a link that silently drops half its data — and on a login redirect, an open redirect vulnerability. A value going inside a URL always needs component encoding.

Double encoding and how to spot it

Double encoding happens when already-encoded text is encoded again. A space becomes %20, then the % itself gets encoded to %25, producing %2520. The link still looks plausible and no longer works.

It is nearly always caused by a value passing through two layers that each try to be helpful — a framework that encodes automatically, plus an application that encodes again before handing it over. The symptom is literal %20 text appearing on a page, or a search for hello world returning results for hello%20world.

This tool flags input containing %25 followed by hex digits, which is the signature. The fix is architectural rather than textual: find which layer is encoding and stop the other one doing it too. Decoding twice to "fix" the symptom leaves the real bug in place, and it will produce a different broken URL the next time the input contains a literal percent sign.

The plus sign, and other historical oddities

A space can be encoded as %20 or as +, and which is correct depends on where in the URL you are.

+ for space comes from the application/x-www-form-urlencoded format used by HTML form submissions. It is valid in a query string and invalid in a path — in a path, + is a literal plus sign. So /search?q=hello+world means "hello world", while /files/hello+world.txt means a file with a plus in its name.

Because servers differ in how strictly they apply this, %20 is the safer choice everywhere: it means a space in every position, unambiguously. This tool encodes spaces as %20, and decodes + as a space only in query-string context.

Two more worth knowing. The characters -, ., _ and ~ are unreserved and never need encoding — a tool that escapes them is being over-cautious and producing uglier URLs than necessary. And the fragment after # is never sent to the server, so encoding it matters only for the client.

How to use the URL Encoder & Decoder

1. Choose encode or decode

   The tool guesses from the input — text containing % escapes is assumed to be encoded — but you can override it.

2. Pick the right mode

   Component for a single value going into a URL. Full URL for tidying a complete address. When in doubt, and the text is going inside a URL, use component.

3. Check the parameter breakdown

   If you pasted a full URL, each query parameter is listed and decoded individually, which is usually the fastest way to see what a long URL actually contains.

4. Watch for the double-encoding warning

   If it appears, the real fix is in your code — find which layer is encoding twice rather than decoding the symptom away.

Frequently asked questions