URL Encoder / Decoder
Encode or decode URL component text safely.
Encode or decode URL component text safely.
The URL Encoder / Decoder uses the browser’s URL component encoding rules. Encoding replaces characters that need escaping inside a URL component with percent-encoded sequences, while decoding converts those sequences back into readable text.
URLs can only safely contain a limited set of characters, so spaces, symbols and non-English characters must be percent-encoded before being included in a web address or query string, which is essential whenever you're building links that include user input.
For related tasks, try Base64 Encoder / Decoder, HTML Entity Encoder / Decoder or JSON Formatter & Validator.
A space in “hello world” is encoded as %20, producing “hello%20world” when processed as a URL component.
The search query hello world and more becomes hello%20world%20%26%20more when URL-encoded, with the space becoming %20 and the ampersand becoming %26, since an un-encoded ampersand inside a URL's query string would otherwise separate two different parameters.
URL encoding and HTML entity encoding solve different problems and are not interchangeable; URL encoding protects characters that would otherwise break a web address itself, while HTML entity encoding protects characters with special meaning inside HTML markup on the rendered page.
A web address can safely contain only a limited set of characters. Others are written as a percent sign followed by two hexadecimal digits. A space is %20, an ampersand is %26, a question mark is %3F and the letter e with an acute accent is %C3%A9, because non-English characters are first converted to UTF-8 bytes. Encoding makes sure a value is not mistaken for part of the address structure.
Only the variable pieces, such as a search term in a query string, should be encoded. If you encode a whole address, the colon and slashes become percent codes and the link stops working. JavaScript has two functions: encodeURI keeps the address structure, and encodeURIComponent encodes everything that could confuse a value. For query values the component version is the right choice.
In the query part of a form submission a space is often written as a plus sign, while elsewhere it is %20. When you decode, a plus sign may need to become a space depending on where it came from. A literal plus sign in a value must be written as %2B. If search terms with plus or spaces come back wrong, this difference is the usual cause.
Double encoding happens when you encode an already encoded string, and %20 becomes %2520. Decoding fails on malformed sequences such as a percent sign not followed by two valid hexadecimal digits. Mixed character sets can produce odd symbols, so use UTF-8 consistently. When debugging a broken link, decode it once and read it. Do not put secrets in URLs, since addresses are stored in browser history and server logs.
When you build a link with a query, encode each value separately. A search for rock and roll with an ampersand, typed as rock & roll, becomes q equals rock%20%26%20roll, because an unencoded ampersand would start a new parameter. A plus sign in an email address, such as name+tag@example.com, must be %2B in a query, or the plus may be read as a space. If a link is passed as a value inside another link, such as a redirect address, encode it once, and never encode it twice.
The text Cafe & Bar 100% with an accent on the final e of Cafe is encoded so that the accented letter becomes %C3%A9, because it is represented by two bytes in UTF-8, and the spaces become %20, the ampersand %26 and the percent sign %25. The result is Caf%C3%A9%20%26%20Bar%20100%25. If you left the ampersand unencoded in a query string, the server would read Bar 100% as a new parameter. Decoding reverses the steps, which is useful when you read addresses copied from logs or analytics.
Letters, digits and the four characters hyphen, period, underscore and tilde are safe and never need encoding. Reserved characters such as colon, slash, question mark, hash, ampersand, equals, plus, comma and semicolon have special meaning in an address, so if you want to use them as plain data inside a value, you must encode them. Spaces, quotes, angle brackets and non-English letters also need encoding. The rule of thumb is to encode every value that you put into a query string, and to leave the fixed parts of the address alone.
Forms submitted from a browser use a format in which spaces are plus signs, so a search for rock and roll may appear as rock+and+roll. A redirect parameter that contains another address must be encoded as a whole: the address https://example.com/a?b=1 inside a parameter becomes https%3A%2F%2Fexample.com%2Fa%3Fb%3D1. Campaign tracking parameters add several encoded values to a link. When building links in code, use the language's built-in functions for building query strings instead of joining text by hand, as they handle the details correctly.
Never trust data that arrives in an address, since users can change it. Validate and encode when you use it, especially in redirects, which attackers use for open redirect scams, and in database queries. For public pages, short readable addresses with hyphens are better than long encoded ones, so choose slugs made of lowercase letters, digits and hyphens. Non-English addresses can work, and browsers show them readably, but when copied they turn into long percent codes, which makes them harder to share. Keep addresses stable once they are published.
A URL is a web address. Percent-encoding replaces unsafe characters with a percent sign and two hexadecimal digits. Reserved characters have special meaning in an address, and unreserved characters are always safe. A query string is the part after the question mark that carries parameters. A fragment is the part after the hash. UTF-8 is the encoding used for non-English characters. Double encoding happens when text is encoded twice. A slug is the readable part of a path.
Letters, digits, hyphen, period, underscore and tilde never need encoding. A space is %20, an ampersand %26, an equals sign %3D, a plus sign %2B and a slash %2F. Encode each query value separately, not the whole address. If a link shows %2520, it was encoded twice. Use the language's built-in functions when you build addresses in code, and decode once to read an address.
Encoding replaces characters that have a special meaning in an address with a percent sign and two hexadecimal digits, so a space becomes %20 and an ampersand becomes %26. In an HTML form, a space may appear as a plus sign instead. Encode each value, such as a search term, separately and then put the pieces together, because encoding a complete address would also encode the slashes, the question mark and the equals signs that give the address its structure. Never encode a value twice, since %20 would become %2520. Decoding is useful for reading links that contain long codes, but do not open a link whose destination you do not trust.
It uses component encoding, so characters such as : and / are encoded too. Use it for query values, path components or individual pieces rather than blindly encoding an entire URL.
It represents certain bytes with a percent sign followed by hexadecimal digits.
Yes. Malformed percent sequences can produce an error.
Both %20 and + can represent a space in URL encoding depending on the context; %20 is the general-purpose percent-encoding for a space, while + is specifically used within query string parameters in many web frameworks.
Typically only the variable parts, such as a search query or parameter value, need encoding; the fixed structural parts of a URL should not be encoded, since that would break the URL's structure.