URL Encoder / Decoder Developer Tool

What percent-encoding does

A URL can only contain a limited set of characters safely — letters, digits, and a handful of punctuation marks (- _ . ~) — plus a small set of characters reserved for the URL's own syntax (: / ? # [ ] @ ! $ & ' ( ) * + , ; =). Anything else, including spaces, non-ASCII characters, and reserved characters used literally rather than structurally, has to be percent-encoded: represented as % followed by the character's byte value in hexadecimal. A space becomes %20, an ampersand used as literal text (not as a query-parameter separator) becomes %26, and a non-ASCII character like é becomes its UTF-8 bytes each percent-encoded in turn (%C3%A9).

Component encoding vs full-URL encoding

JavaScript's encodeURIComponent() and encodeURI() (the two modes this tool offers) exist because a single value can mean different things depending on where in a URL it sits. encodeURIComponent escapes almost everything except unreserved characters — it's the right choice for a single value that's going into a query parameter or path segment, since it also escapes &, =, and ?, which would otherwise be misread as URL structure rather than as part of your data. encodeURI is meant for encoding an entire URL that's already structurally correct, so it leaves those structural characters (: / ? # & =) alone and only escapes things that are genuinely invalid anywhere in a URL, like spaces. Using encodeURI on a single query value is a common bug, since it silently leaves & and = unescaped and lets a value inject extra query parameters it shouldn't be able to.

Where this shows up in Laravel

Route parameters and query strings pass through the same percent-encoding rules on the way in — Laravel decodes them automatically before your route or controller ever sees the value, so $request->query('q') or a bound route parameter already comes back as plain text, not the raw encoded form. Building a URL to send elsewhere (an external API call, a redirect with a return-to parameter) is the direction where encoding still needs to happen explicitly. See the routing guide for how named routes and route() generate URLs, and the mail and notifications guide for an example building a link inside a notification email.

Common mistakes

Double-encoding is the most common trip-up: running an already-encoded string through the encoder again turns %20 into %2520, since the literal % character itself gets encoded a second time. This usually happens when a value is encoded once by application code and then encoded again by a library or framework that assumes it's still raw. The reverse mistake — decoding a value that was never encoded — is usually harmless, since plain text with no % sequences decodes back to itself unchanged, but it's still worth checking the input if a decode produces unexpected characters, since a stray % followed by non-hex digits will throw rather than silently pass through.