URL Encoder/Decoder
Encode and decode URL
Invalid URL
Tips
- The Japanese character「あ」encodes to
%E3%81%82in UTF-8 percent-encoding. - A space may become
%20in URL paths or+in query parameters — this reflects the difference between RFC 3986 and the HTML form encoding spec. - Reserved characters such as
?,&, and=must be encoded when used as parameter values. - Useful when including non-ASCII characters in REST API query parameters or when safely passing redirect URLs.
FAQ
%XX hex format safe for use in URLs. Decoding reverses that process back to the original readable text.%20 in URL path segments (per RFC 3986). Use + only in application/x-www-form-urlencoded query strings (HTML form data). When in doubt, %20 is the safer choice.- _ . ~ — can appear in URLs without encoding. All other characters, including spaces and reserved characters like & and =, must be percent-encoded when used as parameter values.
Side Note — The Birth of the URL: Tim Berners-Lee and the Dawn of the World Wide Web
The URL was designed in 1991 by Tim Berners-Lee, the inventor of the World Wide Web. It was originally conceived for ASCII characters only, which is why multibyte characters (such as Japanese) and special characters must be represented using percent-encoding.
The URL of the very first web page on the internet, http://info.cern.ch/hypertext/WWW/TheProject.html, is still accessible today. Emoji domains (e.g., 🍕.ws) are technically possible and are internally converted to Punycode (the xn-- format). While URLs can theoretically exceed 2,000 characters, practical limits imposed by browsers and servers are around 2,048 characters.
RFC 3986 defines the URL specification, but the distinction between %20 (space) and + (space) remains a frequent source of confusion. %20 is the URI standard; + is used in the HTML form application/x-www-form-urlencoded format — the choice depends on the context.