URL Encoder / Decoder

URL encoding, also called percent encoding, is the mechanism for representing characters in a URL that aren't allowed in their raw form. The URL specification (RFC 3986) defines a limited set of characters that are safe in URLs: letters, digits, hyphens, periods, underscores, and tildes. Everything else needs to be converted to a percent-encoded format before it can safely travel through the infrastructure of the web.

The encoding works by taking the character's byte value in UTF-8 and representing each byte as a percent sign followed by two hexadecimal digits. A space becomes %20. An ampersand becomes %26. A forward slash becomes %2F. The at sign becomes %40. The Japanese character for "cat" (which is three bytes in UTF-8) becomes %E7%8C%AB. Each byte gets its own percent-hex pair, which is why non-ASCII characters produce longer encoded sequences.

This system exists because URLs serve as both human-readable addresses and machine-parseable instructions. The question mark in a URL separates the path from the query string. The ampersand separates query parameters. The forward slash separates path segments. The hash mark indicates a fragment. If any of these characters appeared in actual content like a search query or a file name, parsers couldn't distinguish structure from data. Percent encoding is the escape hatch that lets any character exist in a URL without being misinterpreted as structural syntax.

Every time a URL contains characters outside the safe set, encoding is required. In practice, this happens constantly.

• Query parameters with user input. A search URL like example.com/search?q=cats & dogs breaks because the space and ampersand have structural meaning in URLs. Encoded correctly: example.com/search?q=cats%20%26%20dogs.
• File names with special characters. A PDF named "Q1 Report (Final).pdf" can't be linked as-is in a URL. The spaces and parentheses need encoding: Q1%20Report%20%28Final%29.pdf.
• International characters in paths. A page about a German city might use example.com/cities/M%C3%BCnchen where the umlaut u is encoded. Many modern browsers display the decoded version in the address bar while transmitting the encoded version to the server.
• UTM parameters and tracking. Campaign URLs with UTM parameters often include values with special characters. A campaign name like "Spring Sale - 20% Off!" needs encoding: utm_campaign=Spring%20Sale%20-%2020%25%20Off%21. The percent sign itself needs to be encoded as %25.
• API calls and webhook URLs. URLs constructed programmatically for API requests, webhook endpoints, and callback URLs frequently contain tokens, hashes, and parameter values with characters that need encoding.
• Email and document links. Links embedded in emails, PDFs, Word documents, and other non-web contexts sometimes lose their encoding when the document's formatting engine modifies the URL.

encodeURI encodes a full URL while preserving characters that have structural meaning in URLs. It does not encode colons, slashes, question marks, hash marks, ampersands, equals signs, plus signs, or at signs. Use it when you have a complete URL and want to ensure any special characters in the path or query values are encoded without breaking the URL's structure.

encodeURIComponent encodes a single value that will be inserted into a URL. It encodes everything except letters, digits, hyphens, underscores, periods, tildes, exclamation marks, asterisks, single quotes, and parentheses. Critically, it encodes colons, slashes, question marks, ampersands, equals signs, and hash marks because these characters should not have structural meaning inside a parameter value.

When the wrong choice breaks things. If you use encodeURIComponent on a full URL, you'll encode the colons and slashes that make it a valid URL: https%3A%2F%2Fexample.com%2Fpage is not a clickable URL. If you use encodeURI on a query parameter value that contains an ampersand, the ampersand won't be encoded and will split your intended single parameter into two.

This tool provides both modes. Use Full URL encoding when pasting a complete URL that might have special characters in its path. Use Component encoding when preparing a value that will be inserted into a query parameter, a form field, or any context where the value must not interfere with URL structure.

Double encoding happens when an already-encoded string gets encoded again. The percent sign in %20 gets encoded to %25, turning %20 into %2520. The URL now contains a literal %20 in the decoded value rather than a space.

This happens when multiple systems in a pipeline each apply encoding without checking whether the string is already encoded. A CMS encodes a URL, then a CDN encodes it again, then a redirect rule encodes it a third time.

How to spot it. If you see %25 in a URL, something has been double-encoded because %25 is the encoding of the percent sign itself. The string %2520 is the telltale of a double-encoded space (the % from %20 was re-encoded to %25).

How to fix it. Decode the URL completely first, then encode it exactly once. Never encode a string without knowing whether it's already encoded. This tool includes a detection feature that warns you when the input appears to be already encoded, preventing accidental double encoding.

This distinction has caused more subtle bugs than almost any other URL encoding question.

The origin. HTML forms using the application/x-www-form-urlencoded content type encode spaces as + signs. This convention dates back to the earliest web forms and remains the default behavior for HTML form submissions.

The conflict. In the URL path (everything before the question mark), a plus sign is a literal plus sign, not a space. example.com/a+b is a path containing a literal plus. example.com?q=a+b is a query parameter where the plus represents a space.

Where bugs happen. A system that decodes + as a space in a path segment turns example.com/c++ (a page about C++ programming) into a path with two spaces. A system that doesn't decode + as a space in a query string preserves the literal plus when the sender intended a space.

The safe default. Using %20 for spaces works correctly in both paths and query strings. It's never ambiguous. This tool defaults to %20 and offers + encoding as an explicit option for contexts where form-compatible encoding is specifically required.

• Encoding characters that are already safe. Letters, digits, hyphens, underscores, periods, and tildes don't need encoding. Over-encoding makes URLs unnecessarily long and harder to read in logs and analytics.
• Not encoding the percent sign. A literal percent sign in URL content must be encoded as %25. If your query parameter value is "20% off," the URL needs ?promo=20%25%20off. Writing ?promo=20%20off means the %20 is interpreted as an encoded space.
• Encoding an entire URL when only a parameter value needs it. Encoding https://example.com/page?q=hello world with encodeURIComponent produces https%3A%2F%2Fexample.com%2Fpage%3Fq%3Dhello%20world, which is no longer a valid URL. Only the parameter value needs encoding.
• Assuming all servers handle encoding identically. Different web servers, CDNs, and application frameworks decode URLs differently. Some normalize %2f by decoding it before routing. Others treat it literally. Test your encoded URLs against your actual server.
• Ignoring encoding in redirects. A redirect from an old URL to a new URL needs correct encoding on both sides. A redirect rule matching a decoded path won't fire when the browser sends the encoded version.
• Manually constructing encoded URLs by character replacement. Replacing spaces with %20 using find-and-replace is fine for spaces alone but misses every other character that needs encoding. Use proper encoding functions or this tool to handle the full character set correctly.