The URL Encoder and Decoder percent-encodes text for use in URLs and decodes percent-encoded text back, with the two scopes the web actually distinguishes: component encoding for a single value inside a URL, and full-URL encoding that preserves the URL's structure. Paste text, pick encode or decode and the scope, and the result is produced locally.
How It Works
Encoding replaces each unsafe byte of the UTF-8 representation with a percent sign and its two-digit hex value: a space becomes %20, an ampersand %26, and a non-ASCII character such as é becomes two encoded bytes, %C3%A9. Component scope (encodeURIComponent) encodes everything except letters, digits, and a small unreserved set, including the structural characters / ? & = that would otherwise change the URL's meaning. Full scope (encodeURI) leaves those structural characters intact and encodes only what cannot legally appear in a URL at all. Decoding reverses the process and also treats a plus sign as a space, matching form-encoded query strings, and malformed percent sequences return an error rather than garbage.
Choosing the scope, the whole game
| Scope | Encodes & ? = / | Use for | |---|---|---| | Component | Yes | One query value, one path segment, any user-supplied fragment | | Full URL | No | Sanitizing a complete URL that already has correct structure |
The classic bug is encoding a full URL with the component scope, which encodes the :// and every slash and produces an unusable string; the reverse bug, putting a raw user value containing & or # into a query string unencoded, silently truncates the value or injects an extra parameter. Rule of thumb: build URLs from pieces, encode each user-supplied piece with component scope, and never full-encode something you assembled yourself.
Worked example
The search phrase "rock & roll #1" encoded as a component becomes rock%20%26%20roll%20%231: the spaces, the ampersand (which would have split the query into two parameters), and the hash (which would have started a fragment and dropped the rest) are all neutralized. Decoded with this tool, that string returns the original exactly, including the handling of +, which in query strings means a space: decoding rock+roll gives "rock roll", while a literal plus in data must arrive encoded as %2B to survive.
Where encoding bugs actually bite
Double encoding is the professional classic: a value encoded once by the framework and again by hand arrives as %2520, decodes once to %20, and displays as a literal "%20" in the UI. The fix is a single encoding layer with known ownership. The other repeat offender is assuming decoding sanitizes: a decoded string is just a string, and dropping it into HTML, SQL, or a redirect without context-appropriate escaping reopens the injection holes encoding never claimed to close. This decoder is for inspection and debugging, not for making untrusted input safe.
Limitations
The tool implements the standard JavaScript URI functions and form-style plus handling on decode. It does not implement every legacy charset (non-UTF-8 percent encodings from old systems will decode to mojibake), nor does it parse or validate URL structure beyond encoding. Extremely long inputs are bounded by the browser's text handling, not by the encoder.
Frequently Asked Questions
Should a space be %20 or +?
In a URL path or a strictly built query, %20 is always safe. The + form means space only inside form-encoded query strings (application/x-www-form-urlencoded); this decoder accepts it there, matching what servers do.
Why did my full URL break after encoding?
It was encoded with component scope, which encodes the scheme separator and slashes. Re-encode with full-URL scope, or better, encode only the individual values you are inserting into an existing URL.
Does encoding hide the data?
No. Percent-encoding is a transport representation anyone can reverse with this very tool. It exists so special characters survive the trip, not to protect secrets; encryption and access control do that job.