URL Encoder/Decoder
Encode and decode URLs and query strings
How to use URL Encoder/Decoder
Encode and decode URLs and query strings. Supports percent-encoding and URI components. Free online URL encoder decoder tool.
What is URL encoding used for?
URLs can only contain a limited set of ASCII characters. Special characters — spaces, accents, punctuation, and non-ASCII characters — must be encoded as percent-encoded sequences (%XX) to be safely transmitted in a URL.
- Query parameters: Passing user input as URL parameters requires encoding. A search for "café & croissant" becomes
caf%C3%A9%20%26%20croissantin the URL. - API requests: Building API URLs programmatically — encoding parameters before appending them to the base URL prevents malformed requests and security issues.
- Form data submission: HTML forms with method="GET" encode form values into the URL. Understanding this encoding helps debug form submissions and reconstruct the original values.
- Link sharing: Sharing URLs containing non-ASCII characters (accented letters, CJK characters) — many platforms corrupt these without proper encoding.
- Debugging: Decoding an encoded URL to read the original parameters — useful when inspecting network requests in browser DevTools.
Encoding rules: Letters (A-Z, a-z), digits (0-9), and the characters -_.~ are never encoded. Everything else is encoded as % followed by two hex digits representing the UTF-8 byte values.
Frequently Asked Questions
What is the difference between encodeURI and encodeURIComponent in JavaScript?
encodeURI encodes a complete URL — it leaves URL structural characters (/, ?, &, #, :) unencoded since they have meaning in the URL. encodeURIComponent encodes everything except letters, digits, and -_.~* — used for individual parameter values. Always use encodeURIComponent for query parameter values.
What is the difference between + and %20 for spaces?
Both represent a space in URL encoding, but in different contexts. %20 is correct for all URL components. The + sign represents a space only in application/x-www-form-urlencoded (HTML form data) — not in path segments. Using + in a path encodes a literal plus sign, not a space.
Why does decoding twice cause problems?
If %252F appears in a URL, it encodes %2F (which itself encodes /). Decoding once gives %2F. Decoding twice gives /. Double-encoding occurs when a value is encoded and then the whole URL is encoded again. It causes security issues (path traversal attacks) when servers decode URLs multiple times.
What characters must be encoded in a URL path?
Reserved characters with special meaning must be encoded in path segments: space (%20), # (%23), % (%25), ? (%3F), and others. Forward slash / is the path separator — to include a literal slash in a path segment, encode it as %2F. Some servers decode %2F back to / which can be a security issue.
What is Punycode and how does it relate to URL encoding?
Punycode converts internationalized domain names (IDN) containing non-ASCII characters to ASCII-compatible encoding. 'münchen.de' becomes 'xn--mnchen-3ya.de' in Punycode. This is different from percent-encoding — it applies specifically to domain names, not paths or parameters.
URL encoding vs Base64 vs HTML entities
URL encoding (percent-encoding) makes data safe for URLs. Base64 encoding makes binary data safe for text contexts (email, JSON). HTML entities make special characters safe for HTML: & becomes &, < becomes <. Each solves the same problem — representing data in a restricted character set — but for different target contexts. Using the wrong encoding for the context causes display errors or security vulnerabilities.