URL Encoder/Decoder

Convert any text to URL-safe percent encoding instantly. Our encoder handles spaces, special characters, Unicode, and emojis.

Choose between:

• component encoding (for query values)
• URI encoding (preserving URL structure)
• form data encoding (+ for spaces)

Decode any percent-encoded URL back to readable text. Paste encoded URLs, query strings, or individual parameters and see the original text instantly.

Handles:

• %HH sequences
• plus-as-space
• multi-byte UTF-8 characters

URL encoding works by replacing any character that is unsafe or reserved in a URL with a percent sign followed by two hexadecimal digits representing that character's byte value, a scheme formally defined in RFC 3986 by the IETF.

A space becomes %20, an ampersand becomes %26, and a slash becomes %2F. Non-ASCII characters are first converted to their UTF-8 byte sequence, then each byte is percent-encoded, so the letter 'é' becomes %C3%A9.

According to MDN Web Docs, browsers apply this automatically through functions like encodeURIComponent. Only unreserved characters (A-Z, a-z, 0-9, hyphen, underscore, period, tilde) are left untouched.

encodeURI encodes a complete URL while preserving reserved structural characters, whereas encodeURIComponent encodes a single component and escapes those structural characters too.

As documented by MDN Web Docs, encodeURI leaves :, /, ?, #, &, and = intact so a whole address stays functional, making it right for full URLs. encodeURIComponent escapes everything except the RFC 3986 unreserved set, so it is the correct choice for query-parameter values, path segments, or fragment text that might contain reserved characters.

Using encodeURI where encodeURIComponent is needed is a common bug: an unencoded & inside a value will be misread as a parameter separator, silently corrupting the request.

RFC 3986 divides URL characters into unreserved and reserved sets, and this distinction determines what gets percent-encoded.

• Unreserved characters are the letters A-Z and a-z, digits 0-9, and the four marks hyphen, underscore, period, and tilde; these never require encoding.
• Reserved characters include the general delimiters : / ? # [ ] @ and the sub-delimiters ! $ & ' ( ) * + , ; = which carry syntactic meaning.

Per the IETF specification, reserved characters may appear unencoded when serving their delimiter role but must be percent-encoded when used literally inside a component. Everything outside both sets, including spaces and Unicode, should always be encoded.

URLs use %20 for spaces because the space character is not allowed to appear literally in a URI under RFC 3986, so it is percent-encoded to its ASCII byte value, hex 20.

There is a second convention: in application/x-www-form-urlencoded data, the format used by HTML form submissions and many query strings, a space is encoded as a plus sign (+) rather than %20, as specified by the WHATWG URL Standard and W3C form specifications.

This is why decoders must know their context. %20 is universally safe in the path, query, and fragment, while + only means space inside form-encoded query data and is a literal plus elsewhere.

URL encoding handles Unicode by first converting each character to its UTF-8 byte sequence and then percent-encoding every individual byte. The Unicode Consortium defines the code points, and UTF-8 (specified in RFC 3629) maps them to one to four bytes.

For example:

• A single-byte ASCII character like 'A' stays as 'A'
• 'é' encodes to %C3%A9
• the CJK character '日' becomes %E6%97%A5
• an emoji such as 😀 encodes to four bytes, %F0%9F%98%80

MDN Web Docs notes that JavaScript's encodeURIComponent operates on UTF-8 by default. Decoders reverse this by collecting the percent-encoded bytes and reinterpreting them as a UTF-8 stream to recover the original text.

Double encoding happens when an already percent-encoded string is encoded again, turning each % into %25 so that %20 becomes %2520 and the value can no longer be read correctly.

This is a frequent source of broken links and, per OWASP, a security concern because attackers use double encoding to slip malicious input past filters that decode only once.

To avoid it, encode a value exactly one time at the point where it enters the URL, and never re-encode data that came from another encoded source. If you are unsure whether a string is already encoded, decode it first; if the output changes and looks readable, it was encoded, and you should not encode it again.

URL encoding is not secure and provides no confidentiality; it is a reversible transformation for transport safety, not encryption. Anyone can decode a percent-encoded string instantly, so sensitive data placed in a URL remains fully readable and, as OWASP warns, is also exposed in browser history, server logs, and Referer headers.

Encoding only ensures special characters do not break URL syntax. Encryption, by contrast, uses a key and algorithms like AES (standardized by NIST) to make data unreadable without that key.

The correct security use of encoding is combined with proper output escaping to prevent injection attacks; never treat it as a way to hide or protect information.

To encode a query string correctly, apply encodeURIComponent to each parameter key and value separately before joining them with & and =, rather than encoding the whole assembled string at once.

This ensures that reserved characters inside a value, such as an & or = in user input, are escaped to %26 and %3D so they cannot be mistaken for delimiters, following the application/x-www-form-urlencoded rules described by the WHATWG URL Standard. For example, the value 'hello world&x=1' must become 'hello%20world%26x%3D1'.

According to MDN Web Docs, the URLSearchParams API automates this safely. Always encode user-supplied data before inserting it into a query string to prevent parameter injection and malformed requests.

The most common URL encoding mistake is choosing the wrong function: using encodeURI on a query value leaves &, =, and ? unescaped, letting user input corrupt the URL structure.

Other frequent errors, several flagged by OWASP and MDN Web Docs, include:

• double encoding a value so %20 becomes %2520
• forgetting that + means space only in form-encoded data
• encoding an entire URL after it is built instead of encoding each component beforehand

Developers also mishandle UTF-8 by decoding bytes as Latin-1, which produces mojibake for accented and non-Latin text. Finally, never rely on encoding for security; failing to also escape output for the target context leaves injection vulnerabilities open despite valid percent encoding.