Toolverse

URL Encoder / Decoder

Encode text for use in URLs and query strings, or decode percent-encoded URLs back to readable text — with full Unicode support, all in your browser.

Output

How to use it

Pick Encode or Decode and paste your text or URL. By default it encodes a single value (escaping characters like & = ? /). Turn on 'Full URI' to keep a URL's structure intact and only escape unsafe characters. Click copy to grab the result. URL encoding, also called percent-encoding, is the standard way to make text safe to place inside a URL or a query string. Any character outside a small set of reserved and unreserved ASCII characters is replaced with a percent sign followed by two hexadecimal digits representing the byte value of that character — a space becomes %20, an ampersand becomes %26, and so on. URLs only allow a limited set of ASCII characters: letters, digits, and a handful of punctuation marks like - _ . ~. Everything else, including spaces, quotation marks, and non-English letters, has to be escaped before it can travel safely inside a URL. Without encoding, a browser or server can misread where one part of a URL ends and another begins — an unescaped & inside a value looks like the start of a new query parameter, an unescaped ? looks like the start of the query string itself, and an unescaped # gets treated as a fragment identifier, silently cutting off everything after it. Take the phrase "café & bar" as an example query value. The space characters become %20, the ampersand becomes %26, and the accented é — which takes two bytes in UTF-8 — becomes %C3%A9. Percent-encoded, the phrase turns into caf%C3%A9%20%26%20bar. Decoding reverses the process: each %XX pair is read back as a UTF-8 byte and reassembled into the original character, so decoding that string returns café & bar exactly as it started. Encoding a whole URL and encoding a single query-string value are different jobs. Full-URI encoding escapes unsafe characters but deliberately leaves a URL's structural characters — / : ? & = # — untouched, since removing them would break the URL's own syntax. Component encoding (the default here) escapes those same characters too, because a value being inserted into a query string should never be allowed to introduce a stray & or = that a server would mistake for a new parameter. Percent-encoding shows up constantly in everyday web work: building a query parameter from user input, sharing a link that includes a search term or filter, assembling API request URLs, submitting form data over GET, and constructing UTM parameters for marketing links. It's also the fix for the classic "malformed URI" error thrown by decodeURIComponent — that error means the string being decoded contains a % that isn't followed by two valid hex digits, usually because it was encoded incorrectly or encoded twice.

Frequently asked questions

What's the difference between encoding a component and a full URI?
Component encoding (the default) escapes reserved characters like & = ? /, so it's right for a single query value. Full-URI encoding leaves those characters in place, so it's right for an entire URL.
Does it handle non-English characters?
Yes. Text is percent-encoded as UTF-8, so accents, emoji and CJK characters encode and decode correctly.
What if I paste invalid encoded text?
If a percent-escape is malformed (like a lone %), decoding shows an error instead of producing garbage.
Why does a space sometimes become %20 and other times a +?
Both represent a space, but in different contexts. Percent-encoding (RFC 3986) always uses %20, which is what this tool produces. The + character is a legacy convention from the older application/x-www-form-urlencoded format used by HTML form submissions, where + means space and a literal plus sign must itself be encoded as %2B.