URL Encoder & Decoder

URLs and query strings can only safely contain a small set of characters (letters, numbers, and a few symbols: - _ . ~). All other characters — including spaces, ampersands, equals signs, non-Latin characters, and emojis — must be percent-encoded (also called URL encoding) to be transmitted correctly over the web.

Our free URL Encoder & Decoder performs percent-encoding per RFC 3986. Reserved characters like ? & = # @ : / are replaced with % followed by their two-digit hexadecimal value. Spaces become %20 (or sometimes + in the application/x-www-form-urlencoded format; we use the standard %20).

Use the Encoder when you need to include a URL inside another URL query parameter (e.g., a redirect parameter), or when a search query contains special characters. Use the Decoder when you receive a URL with percent-encoded characters and want to see the original human-readable value.

Important: Always encode individual query parameter values, not the entire URL. Encoding the full URL would encode the ? and & separators and break the structure. Our tool operates on the text as-is; it is up to you to encode only the parts that should be literal values.

Frequently Asked Questions

When should I use URL encoding?

Any time a string containing non-alphanumeric characters is placed in a URL query parameter (e.g., ?q=search+term), in a URL path segment, in a Location header, or in form data submitted as application/x-www-form-urlencoded. Browsers and HTTP libraries typically do this automatically, but manual encoding is often needed when constructing URLs programmatically.

Space as %20 vs +: which is correct?

Both are widely used but in different contexts. %20 is correct in URL paths and per RFC 3986. The plus sign (+) is only valid for spaces in the query string of application/x-www-form-urlencoded data (HTML form submission convention). Our encoder uses %20, which works in all contexts.

My decoded URL looks garbled — why?

The most common cause is double encoding: the original was already encoded, then encoded again, e.g., " " → "%20" → "%2520". Decoding twice would restore the original. Another cause is mixed encoding of non-UTF-8 data (rare on modern web but can happen with legacy systems).

Does the encoder handle emojis and non-English text?

Yes. We first encode the text as UTF-8 bytes (which represents Unicode code points as 1–4 bytes each), then percent-encode each byte. This is the standard that all modern browsers and servers expect. For example, 😊 becomes %F0%9F%98%8A.

Frequently Asked Questions

Related Tools

Unit Converter

Base64 Encoder & Decoder