URL Encoder & Decoder

It is the mechanism that lets a URL carry characters it otherwise could not. Each disallowed byte is replaced by a percent sign and its two-digit hexadecimal value, so a space becomes %20 and an ampersand becomes %26. It is also called percent-encoding, which is the more accurate name.

Component encoding escapes the reserved characters that carry structural meaning — & ? = / # + — because inside a single query value they are data, not syntax. Full-URL encoding leaves those intact so an entire URL survives the round trip. Use component encoding for one parameter value, full-URL encoding for a whole address.

Because an unencoded ampersand ends the parameter. In ?q=fish&chips the server sees a parameter q with the value "fish" and a second empty parameter named "chips". Encoding it as %26 keeps it part of the value. The same applies to = and #.

Both appear, in different contexts. Percent-encoding proper uses %20. The plus sign comes from HTML form submission, where the application/x-www-form-urlencoded format encodes a space as +. %20 is safe everywhere; + is only interpreted as a space in that form-encoded context, and is a literal plus elsewhere.

It is encoded as UTF-8 first, then each byte is percent-escaped — so a character outside ASCII becomes several escape sequences. The euro sign is %E2%82%AC, three bytes. This tool uses the browser's own UTF-8 handling, so multi-byte characters and emoji round-trip correctly.

No, and treating it as one causes vulnerabilities. Encoding makes data survive transport; it does not make it safe. Output still needs contextual escaping for HTML, SQL still needs parameterised queries, and a decoder on the far side will happily return whatever was encoded. Double-encoding is a common technique for slipping payloads past filters that decode once.

No. Both directions use the browser's built-in encodeURIComponent and decodeURIComponent, so the work happens in this tab and no request is made.