Fragile characters in URLs often break web server requests or lead to 'URI malformed' exceptions in your application code.
Example Broken Input: Searching for 'hello world!' results in a URL that needs to encode the space and exclamation mark safely.
Why it happens: Certain characters carry special meaning in a URL structure; failing to escape them correctly creates ambiguity and breaks redirects or analytics tracking.
Solution (Use Tool): The URL Encoder / Decoder workshop sanitizes strings using the `encodeURIComponent` standard. It handles multi-layered escapes entirely in your browser to maintain data privacy.
Advanced Notes: Use the decoder to audit complex redirect chains or to extract clean JSON payloads from encoded query parameters.
How to URL Encode or Decode Text
- Type or paste your raw text or URL into the input area.
- Select whether you want to Encode or Decode the string using the toggle switch.
- The converted output appears instantly.
- Click 'Copy' to copy the encoded or decoded string to your clipboard.
Examples
https://example.com/?search=hello world!https%3A%2F%2Fexample.com%2F%3Fsearch%3Dhello%20world!test%40email.comtest@email.com (Decoded)Percent Encoding Explained: RFC 3986
RFC 3986 defines which characters are safe in URLs and how unsafe characters must be encoded. Unreserved characters, including letters, digits, hyphens, periods, underscores, and tildes, can appear as-is. Reserved characters like /, ?, #, &, and = have special meaning in URL structure and must be percent-encoded when used as data rather than delimiters.
Percent encoding converts each byte of a character's UTF-8 representation into a %XX hexadecimal pair. The space character becomes %20 in URL paths. However, in query strings, the application/x-www-form-urlencoded format encodes spaces as + signs, a legacy convention from HTML form submissions.
JavaScript provides two encoding functions with different scopes. encodeURI() encodes a complete URI but leaves reserved characters intact because they serve structural roles. encodeURIComponent() encodes everything except unreserved characters, making it safe for encoding individual query parameter values. Using encodeURI() on a query parameter value would leave characters like & and = unencoded, breaking the query string structure.
Understanding this distinction prevents a common class of bugs where URLs work for simple ASCII inputs but break when users enter special characters, non-Latin text, or values containing reserved URL characters.
Double Encoding: The Most Common URL Bug
Double encoding occurs when an already percent-encoded string passes through an encoding function a second time. The character %20 (a space) becomes %2520 because the percent sign itself gets encoded to %25. The server receives %2520, decodes it once to %20, and displays a literal %20 instead of a space.
This bug is insidious because it only manifests with special characters. URLs containing only ASCII letters and digits work fine regardless of how many times they are encoded. The problem appears when users enter spaces, accented characters, or symbols, making it intermittent and hard to reproduce.
Double encoding commonly happens in redirect chains. A login page encodes the return URL as a query parameter. The authentication service encodes the entire redirect URL again when passing it to another service. By the time the user arrives at their destination, the URL has been encoded twice and no longer matches any route.
To detect double encoding in logs, search for %25 followed by two hexadecimal digits. The string %2520 is almost always a double-encoded space. The fix is to ensure each component in your URL pipeline encodes exactly once: encode raw user input at the point of entry and pass the encoded result through without re-encoding.