URL Encoder / Decoder
Encode, decode, and parse URLs with full component breakdown and query parameter table.
Encodes all special characters including : / ? # [ ] @ ! $ & ' ( ) * + , ; =
About URL Encoder / Decoder
URL encoding, formally known as percent-encoding, is a mechanism defined in RFC 3986 for representing characters in a Uniform Resource Identifier (URI) that would otherwise be interpreted as structural delimiters or are not permitted in certain URI components. The scheme works by replacing each unsafe byte with a percent sign (%) followed by its two-digit hexadecimal representation. For example, a space becomes %20, an ampersand becomes %26, and a forward slash becomes %2F. This ensures that the encoded string can be embedded in a URL without ambiguity -- the parser can always distinguish between a literal character and a delimiter.
Understanding which characters need encoding -- and in which context -- is one of the subtler aspects of web development. The URI specification defines a set of 'unreserved' characters (A-Za-z0-9 and -._~) that never need encoding. 'Reserved' characters (such as :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, and =) have special syntactic meaning in URIs: the question mark separates the path from the query string, the ampersand separates query parameters, and the hash introduces a fragment. When these characters appear as data values rather than as delimiters, they must be percent-encoded to prevent misinterpretation. The JavaScript functions encodeURIComponent and decodeURIComponent handle this correctly for individual URI components, while encodeURI and decodeURI preserve the structural delimiters and only encode characters that are invalid in any part of a complete URI.
This tool allows you to encode plain text into a URL-safe format and decode percent-encoded strings back to their readable form. It is particularly useful when constructing query parameters that contain special characters, debugging URLs that appear garbled due to double-encoding, inspecting redirect URLs embedded inside other URLs, and preparing strings for use in API requests where parameter values must be properly escaped. All processing happens locally in your browser, keeping your data private.
How to Use the URL Encoder/Decoder
- Choose the operation you need: 'Encode' to convert special characters to their percent-encoded equivalents, or 'Decode' to convert percent-encoded sequences back to readable characters.
- Paste or type your input text into the input area. For encoding, enter the raw string that contains characters needing escaping. For decoding, paste the percent-encoded URL or URL component.
- Select the encoding scope: 'Component' mode (equivalent to encodeURIComponent) encodes all characters except unreserved ones, suitable for query parameter values and path segments. 'Full URI' mode (equivalent to encodeURI) preserves structural delimiters like ://?#, suitable for encoding a complete URL.
- Review the output in the result panel. Encoded output will show percent-encoded sequences for all special characters. Decoded output will restore the original readable text.
- If you suspect double-encoding (e.g., %2520 instead of %20), decode the string once and inspect the result. If percent signs remain encoded, decode again. This tool makes it easy to iteratively unwrap multiple layers of encoding.
- Copy the result using the copy button for direct use in your code, API client, or browser address bar.
- For debugging complex URLs, paste the entire URL and decode it to see the human-readable version of all query parameters and their values.
Common Use Cases
Building Safe Query Parameters
When constructing URLs programmatically, query parameter values may contain characters like &, =, and spaces that would break the URL structure if included literally. Encoding the value of each parameter ensures that the URL parser correctly interprets where one parameter ends and the next begins. For example, searching for 'rock & roll' must encode the ampersand to prevent it from being interpreted as a parameter separator.
Debugging Double-Encoded URLs
A common bug in web applications is double-encoding, where an already-encoded string is encoded a second time. This produces sequences like %2520 (the percent sign itself gets encoded) instead of the intended %20. Decoding the URL step by step in this tool reveals each layer of encoding and helps pinpoint where the redundant encoding occurs in your code.
Inspecting OAuth and Redirect URLs
OAuth flows and single sign-on systems frequently embed callback URLs inside other URLs as query parameters. These nested URLs must be fully percent-encoded, which makes them unreadable in their raw form. Decoding the outer URL reveals the redirect target, its parameters, and any embedded state -- essential for debugging authentication flows and verifying that redirect URLs have not been tampered with.
Preparing Data for Form Submissions
When submitting HTML forms with the default content type application/x-www-form-urlencoded, the browser percent-encodes the form data. Understanding this encoding is important when manually crafting POST requests with tools like curl or fetch, or when reading server-side logs that contain encoded form data. This tool lets you decode form payloads to read the submitted values.
Frequently Asked Questions
What is the difference between encodeURI and encodeURIComponent?
encodeURI is designed for encoding a complete URI and preserves characters that have structural meaning in URLs, such as :, /, ?, #, and &. It only encodes characters that are completely invalid in any part of a URI. encodeURIComponent is designed for encoding a single URI component (like a query parameter value) and encodes all characters except unreserved ones (A-Za-z0-9-._~). If you use encodeURI on a query parameter value that contains &, the ampersand will not be encoded and will break the URL structure. As a rule of thumb: use encodeURIComponent for individual values, and encodeURI only when encoding a full URL where you want to preserve its structure.
Why is a space sometimes encoded as %20 and sometimes as +?
The + sign representing a space is a convention from the application/x-www-form-urlencoded content type, which is used by HTML form submissions. In this encoding, spaces become + and the + character itself becomes %2B. In standard percent-encoding as defined by RFC 3986 (used in URI paths and most other contexts), spaces are always encoded as %20. The + convention only applies within form data. When in doubt, use %20 -- it is universally understood.
What is double-encoding and how do I fix it?
Double-encoding happens when an already-encoded string is passed through an encoding function again. For example, a space is first encoded to %20, and then the percent sign is encoded to %25, resulting in %2520. This usually occurs when a framework or library automatically encodes URL parameters, and the developer also encodes them manually beforehand. The fix is to encode the value only once, at the point where it is inserted into the URL. If you are already receiving double-encoded URLs, decode them twice to recover the original value.
Do I need to encode non-ASCII characters like emoji or accented letters?
Yes. URIs are defined to contain only ASCII characters. Non-ASCII characters (such as accented letters, Chinese characters, Arabic script, or emoji) must first be converted to their UTF-8 byte representation, and then each byte is percent-encoded individually. For example, the character 'e' with an acute accent is represented as two UTF-8 bytes (0xC3 0xA9), which become %C3%A9. Modern browsers display the decoded form in the address bar (a concept called Internationalized Resource Identifiers, or IRIs), but the actual HTTP request always sends the percent-encoded version.
Are there any characters that should never be encoded in a URL?
The 'unreserved' characters defined by RFC 3986 -- uppercase and lowercase ASCII letters, digits 0-9, hyphen (-), period (.), underscore (_), and tilde (~) -- should never be percent-encoded. Encoding them is technically valid (a compliant parser will decode them correctly), but it produces unnecessarily long URLs and can cause issues with URL comparison, caching, and canonicalization. Some systems may treat 'example' and '%65xample' (where %65 is the letter 'e') as different URLs even though they decode to the same string.
Is URL encoding the same as HTML encoding?
No. URL encoding (percent-encoding) and HTML encoding (character entity encoding) serve different purposes and use different syntax. URL encoding replaces characters with %XX sequences for safe inclusion in URIs. HTML encoding replaces characters with entity references like & for &, < for <, and ' for an apostrophe, ensuring they are displayed literally in HTML rather than being interpreted as markup. Using the wrong encoding in the wrong context is a common source of cross-site scripting (XSS) vulnerabilities.