URL Encoder & Decoder

How this calculator works

A URL can only carry a limited set of characters. Anything outside that set, or with a structural job in the address, has to be written as a percent sequence before the link is safe to send: a space becomes %20, an ampersand becomes %26, a question mark becomes %3F, and non-ASCII text is encoded as UTF-8 bytes first, so café becomes caf%C3%A9. This tool encodes text and URLs and decodes them back, entirely in your browser. Paste a value, pick Encode or Decode, and copy the result.

The choice that trips most people up is scope. Encode a single value (encodeURIComponent) when it sits inside a URL: a search term, a redirect target, a path segment. It escapes the structural characters too, so https://example.com/search?q=hello world&lang=en as one value becomes https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den, which is exactly right as a parameter value and exactly wrong as a clickable link. Encode a whole URL (encodeURI) when the address must stay clickable: it keeps : / ? & = # intact and only fixes spaces and non-ASCII characters, so the same example stays https://example.com/search?q=hello%20world&lang=en. Worked example: the value "hello world & friends?" encodes to hello%20world%20%26%20friends%3F in value mode.

Two more traps are worth knowing. Spaces have two spellings: %20 is standard percent-encoding and safe everywhere, while + means a space only in HTML form data (application/x-www-form-urlencoded), so a literal plus sign must arrive as %2B or it silently becomes a space. And if a decoded string still shows %20 or %25, it was encoded twice, usually because an encoder ran over an already-encoded value; decode again to resolve it, then fix the step that doubled it. The query-string builder at the bottom of the tool handles the form-encoding rules for you, and the URL parts breakdown shows what a pasted address actually contains, which is the fastest way to read a suspicious redirect or tracking link.