URL Encoder Decoder

The URL Encode/Decode tool converts text to and from percent-encoding — the format that makes data safe to put inside a URL. Encode a string so spaces, symbols, and non-English characters travel correctly, or decode a cryptic %20-filled URL back into readable text. Essential for building query strings, debugging links, and working with APIs. Free and instant in your browser.

What URL Encoding Is

URLs are allowed to contain only a narrow set of ASCII characters — letters, digits, and a handful of symbols. Anything else must be percent-encoded: each unsafe character is replaced by a '%' followed by two hexadecimal digits representing its byte value. A space becomes %20, '@' becomes %40, '#' becomes %23. That's the entire idea — turning unsafe characters into a safe, transmittable form.

How to Use It

1. Paste your text or URL.
2. Encode or decode — choose the direction.
3. Copy the result into your code or browser.

Reserved vs. Unreserved Characters

Knowing which characters need encoding prevents most URL bugs:

The Classic Use Case: A URL Inside a URL

Here's where encoding earns its keep. Imagine a login link that redirects somewhere afterward:

...?redirect=https://site.com/page?id=5&ok=true

The ':', '/', '?', and '&' inside that redirect value will confuse the parser — it'll think '&ok=true' is a separate parameter. URL-encoding the redirect value wraps it into one clean, unambiguous string the server reads correctly. Passing any URL, email, or search term as a parameter requires this.

The %20 vs. + Gotcha

A space is encoded two different ways depending on context, which trips up many developers. In a URL path, a space is %20. But in HTML form data (the format query strings from forms use), a space is +, and a literal plus becomes %2B. So when you decode data from a form, treat '+' as a space; in a path, treat it as a literal plus. Mixing these up corrupts the result.

Non-English Characters

Unicode characters are handled in two steps: first converted to bytes via UTF-8, then each byte percent-encoded. That's why an accented letter such as 'ç' can expand into several triplets (like %C3%A7). UTF-8 is the web standard for this, ensuring text in any language survives the trip through a URL intact.

Encode Once, Decode Once

A frequent bug is double-encoding: encoding an already-encoded string turns its '%' signs into %25, so %20 becomes %2520. Decoding once then yields %20 instead of a space. The rule is simple — encode exactly once and decode exactly once. Also remember encoding applies to the path, query, and fragment; the hostname uses Punycode and the scheme stays plain ASCII.

Free and Private

Encoding and decoding happen entirely in your browser, so your data never leaves your device. Use it to build correct links, debug mysterious '%'-filled URLs, and prepare API parameters — free, with no signup.

URL Encode/Decode FAQs

What is URL encoding?

URL encoding, also called percent-encoding, converts characters that aren't safe in a URL into a '%' followed by two hexadecimal digits representing the character's byte value. For example, a space becomes %20 and '@' becomes %40. It exists because URLs may contain only a limited set of ASCII characters, so anything else — spaces, punctuation, or non-English letters — must be encoded to transmit correctly.

When do I need to URL-encode something?

Whenever you put data into a URL that might contain reserved or unsafe characters — most commonly in query string values. The classic case is passing one URL as a parameter inside another (a redirect): its ':', '/', '?', and '&' characters must be encoded so the server reads the whole thing as a single value instead of misparsing it. Form data, search queries, and API parameters all rely on encoding.

What's the difference between reserved and unreserved characters?

Unreserved characters — letters, digits, and a few symbols like hyphen, underscore, period, and tilde — are always safe and never need encoding. Reserved characters such as '/', '?', '#', '&', '=', and '@' have special structural meaning in a URL (they act as delimiters), so when you want to use one as literal data rather than a delimiter, you must percent-encode it to avoid ambiguity.

Why is a space sometimes %20 and sometimes +?

Both appear because of two related standards. In the path and most of a URL, a space is encoded as %20. But in HTML form submissions (the application/x-www-form-urlencoded format used in query strings from forms), a space is encoded as '+', and a literal '+' becomes %2B. When decoding form data, treat '+' as a space; in a path, treat '+' as a literal plus.

How are non-English characters encoded?

They're first converted to bytes using UTF-8, then each byte is percent-encoded. So an accented letter like 'ç' becomes a sequence of percent-encoded bytes (for example %C3%A7). This is why a single non-ASCII character can expand into several percent triplets — and why UTF-8 is the recommended encoding for URLs.

What is double-encoding and why is it a problem?

Double-encoding happens when you encode a string that's already encoded — the '%' signs themselves get encoded, so %20 becomes %2520. When the receiving system decodes only once, it gets %20 instead of a space. This is a common source of broken links and routing bugs, so encode exactly once and decode exactly once.

Does URL encoding apply to the whole URL?

No — it applies to the path, query, and fragment. The hostname is handled differently: non-ASCII domain names use Punycode, not percent-encoding, and the scheme (like https) and port are always plain ASCII. Encoding the wrong component can break the URL, so encode the data portions, not the structural ones.

Is the tool free and private?

Yes. Encoding and decoding run in your browser, so your data isn't sent anywhere, and it's free with no signup. Paste, convert, and copy.