URL Encoder / Decoder

Encode and decode URLs and query strings with percent encoding. Choose component, full-URI or form-data mode, and convert in both directions as you type.

Percent-encode text for URLs, or decode it back. Type in either box and the other updates immediately. Pick the mode that matches where the value will be used: a single query parameter, a whole URL, or an HTML form submission.

Percent encoding, explained properly

Why URLs need encoding at all

A URL is not free-form text. Characters such as ?, #, &, / and = are reserved: they carry structural meaning, marking where the path ends and the query begins, or separating one parameter from the next. If a value you want to transmit happens to contain one of those characters, the parser on the other end will misread your URL. Percent encoding solves this by replacing the offending byte with a % followed by its two-digit hexadecimal value, so a & inside a value travels as %26 and can never be mistaken for a separator.

Unreserved, reserved, and everything else

RFC 3986 splits the character space into three groups.

  • Unreserved — A-Z a-z 0-9 - . _ ~. These never need encoding and should be left alone. Encoding them anyway is legal but produces uglier URLs and can break naive string comparisons.
  • Reserved — : / ? # [ ] @ ! $ & ' ( ) * + , ; =. These are safe only where they are meant to be structural. Inside a value they must be encoded.
  • Everything else — spaces, control characters, and any non-ASCII text. These always require encoding.

Non-ASCII text and UTF-8

Percent encoding operates on bytes, not characters, so the text must be converted to bytes first. The modern answer is always UTF-8. A € sign is three bytes in UTF-8 (E2 82 AC), so it encodes to %E2%82%AC. Older systems sometimes used the page's own charset, which is why you occasionally still meet a mojibake URL encoded as Latin-1 or GBK. This tool uses UTF-8 throughout, matching what browsers and every current server framework expect.

The three modes, and when each is wrong

encodeURIComponent is the safe default and escapes all reserved characters. Use it whenever you are inserting a value into a URL. encodeURI deliberately preserves reserved characters so a complete URL stays intact — use it only to tidy an already-assembled URL, never on an individual parameter, because it will happily leave an & in your value and corrupt the query string.

Form mode is the odd one out. The application/x-www-form-urlencoded serialisation, which predates the modern URL specifications, encodes a space as + rather than %20. Both are correct in a query string, and servers accept either, but if you are hand-building the body of a POST request you should match the form convention.

The + ambiguity

Because form encoding gives + a special meaning, a literal plus sign in a form value must itself be encoded as %2B. This is the single most common encoding bug in the wild: a base64 string or a phone number in international format is passed through as-is, and the receiving side turns every + into a space. If your data can contain plus signs, either encode them explicitly or avoid form mode.

Double encoding

Encoding an already-encoded string turns each % into %25, so %20 becomes %2520. This is usually a bug — it happens when a value is encoded by application code and then again by a framework or a proxy. If you see %25 in a URL where you did not intend a literal percent sign, you are looking at a double-encoded value. Decoding twice recovers the original, but the real fix is to remove one of the encoding steps.

Open-source notice: implemented with the standard JavaScript encodeURIComponent, encodeURI, decodeURIComponent and decodeURI functions. No third-party library is used.

FAQs

Should I use %20 or + for a space?
Both are accepted in a query string. Use %20 if you want one representation that is valid everywhere, including inside a path segment where + means a literal plus. Use + only when you are producing application/x-www-form-urlencoded data.
Why does my plus sign turn into a space?
Something in the chain is parsing the value as form data, where + is the encoding for a space. Encode literal plus signs as %2B before sending them.
Do I need to encode a slash?
Only when the slash is part of a value rather than a path separator. A file name containing a slash must be sent as %2F, otherwise the server will read it as an extra directory level. Note that some servers reject %2F in paths by default as a traversal precaution.
Is the encoding case-sensitive?
The hex digits may be upper or lower case and both decode identically, but RFC 3986 says to prefer upper case. %2F and %2f are the same character; %2F is the canonical spelling.
Why does decoding fail on my string?
A percent sign must be followed by exactly two hexadecimal digits. A bare % or something like %zz is malformed and the decoder throws. If your text legitimately contains a percent sign, it should have been encoded as %25.
Does this send my data anywhere?
No. Encoding and decoding both run in your browser using the built-in URI functions. Nothing is uploaded.