URL Encoder/Decoder

URL Encoder converts text into a form that is safe to embed in a URL and decodes percent-encoded strings back into readable text. Paste a query value with a space, an ampersand, or Chinese characters and get a valid, copy-paste-ready result. It is a daily tool for anyone building links, API calls, or tracking URLs, and for anyone trying to read a URL from a log or an analytics report where everything is buried under percent signs.

Encode vs Decode

• Encode mode turns readable text into percent-encoded output.
• Decode mode reverses the process, turning percent escapes back into characters.
• Type in the left box and the result appears on the right as you type; the Copy button places it on the clipboard.
• The decode direction uses the matching native function for the selected type, so an encode followed by a decode of the same string returns the original text.

encodeURIComponent vs encodeURI

The two types behave differently on reserved characters. This is the distinction that causes most URL bugs.

Input	Parameter value (encodeURIComponent)	Full URL (encodeURI)
a b&c=d	a%20b%26c%3Dd	a%20b&c=d
https://x.com/p?a=1	https%3A%2F%2Fx.com%2Fp%3Fa%3D1	https://x.com/p?a=1
中	%E4%B8%AD	%E4%B8%AD
a+b	a%2Bb	a+b

Parameter-value mode treats the input as data, so it escapes &, =, /, ?, and : that would otherwise change the URL’s meaning. Full-URL mode treats the input as a URL and preserves those structural characters, encoding only spaces and non-ASCII text. Choosing the wrong mode is the usual cause of a link that silently splits one parameter into two.

Why URLs Need Percent-Encoding

URLs were designed around a small ASCII character set, and several of those characters have structural meaning: ? starts the query, & separates parameters, = assigns a value, and # starts a fragment. Any character outside the safe set — spaces, quotes, brackets, and the entire non-ASCII world — must be represented as a percent sign followed by the UTF-8 byte value in hexadecimal. Non-ASCII text is encoded byte by byte after UTF-8 conversion, which is why one Chinese character becomes three percent triplets. The encoding is reversible and purely mechanical, which is why a decoder can always recover the original text as long as the string is well formed.

Worked Examples

1. Encode the value coffee & tea for a query parameter. Parameter-value mode gives coffee%20%26%20tea, which you can safely append as ?q=coffee%20%26%20tea. Full-URL mode would leave the & and split your value into two parameters.
2. Encode the full link https://example.com/search?q=a b&lang=en. Full-URL mode yields https://example.com/search?q=a%20b&lang=en, keeping the scheme, path, and query delimiters intact while escaping only the space.
3. Encode 中文. Both modes produce %E4%B8%AD%E6%96%87, one percent triplet per UTF-8 byte. Decoding that string returns 中文.
4. Encode the emoji 😀 (U+1F600). Its UTF-8 bytes are F0 9F 98 80, so the output is %F0%9F%98%80.
5. Decode %E4%B8%AD%E6%96%87 in parameter-value mode to get 中文, or decode a partially encoded link to inspect what a redirect actually pointed at.

Why Spaces and Plus Signs Differ

Both functions produce %20 for a space, and both leave a literal + as + in full-URL mode or encode it to %2B in parameter-value mode. The confusing case is form encoding: HTML form GET submissions and application/x-www-form-urlencoded payloads use + for a space. If a value arrives from a form and contains +, this tool will not turn it into a space — decode first, then replace plus signs manually. Keeping the two conventions straight is the single most common source of “my search term became coffee+tea” confusion.

Reserved vs Unreserved Characters

RFC 3986 divides URL characters into unreserved and reserved sets. Unreserved characters — letters, digits, hyphen, underscore, dot, and tilde — never need encoding. Reserved characters fall into two groups: gen-delims such as :, /, ?, #, [, and @, which separate the parts of a URL, and sub-delims such as !, $, &, ', (, ), *, +, ,, ;, and =, which have meaning inside those parts. When a reserved character is used as data rather than as a delimiter, it must be percent-encoded. That is exactly the job of parameter-value mode, while full-URL mode is for strings where the reserved characters are still acting as delimiters.

Common Mistakes

• Encoding a whole URL with parameter-value mode and breaking its ://, ?, and & separators.
• Encoding a query value with full-URL mode and letting & or = act as a delimiter.
• Double encoding, which adds %25 and produces visibly wrong output such as %2520 where a space was expected.
• Assuming !, ', (, ), and * are always escaped. Parameter-value mode leaves them as-is, so an RFC 3986-strict system may still reject the result.
• Decoding a partially encoded string, where a stray % triggers an immediate error rather than a partial result.
• Treating the two modes as interchangeable because they agree on simple ASCII. They diverge the moment the text contains a reserved character.

Related Tools

• URL Parser
• Base64
• HTML Encoder