URL Encoder / Decoder

What Is URL Encoding?

URL encoding, formally defined as percent-encoding in RFC 3986, is a mechanism for representing arbitrary data within a Uniform Resource Identifier (URI) using only the limited character set that the internet's foundational protocols accept. The web was built on ASCII, a character set of 128 characters, and URIs are even more restrictive: they may only contain a defined subset of ASCII characters. Every other character, whether a space, an ampersand, a pound sign, a non-Latin letter, or an emoji, must be translated into a safe representation before it can travel inside a URL.

The translation follows a straightforward rule. The offending character is replaced by a percent sign (%) followed by two hexadecimal digits that represent that character's byte value in UTF-8. A space, for instance, has a byte value of 32 decimal, which is 20 in hexadecimal, so it becomes %20. The at-sign (@) becomes %40. An ampersand (&) becomes %26. The percent sign itself, since it is the escape marker, becomes %25.

There are two categories of characters in a URI. Unreserved characters (the letters A-Z and a-z, digits 0-9, and the symbols hyphen, underscore, full stop, and tilde) may appear in any URL without modification. Reserved characters (such as / ? # [ ] @ ! $ & ' ( ) * + , ; =) carry structural meaning within a URI and must be percent-encoded when used as literal data rather than as delimiters. Every other character, including all non-ASCII text, must also be encoded.

URL encoding is not optional or decorative. Without it, a URL containing a space is technically malformed. Without it, an ampersand embedded in a query value would be misread as a parameter separator. Without it, a hash inside a link target would be mistaken for the start of a fragment identifier. Percent-encoding resolves all of these ambiguities by marking exactly which characters are data and which are structural syntax.

It is worth understanding the distinction between two closely related JavaScript functions that reflect this same split. encodeURIComponent() on MDN Web Docs encodes everything except the unreserved set, making it appropriate for encoding individual query values and path segments. encodeURI(), by contrast, leaves reserved characters and the URL structure intact, making it suitable for encoding a complete URL that is already well-formed. The distinction matters in practice: use encodeURIComponent() on the values inside a URL, and encodeURI() on the URL as a whole.

URL decoding is the reverse operation. A percent-encoded string is parsed for every %XX sequence, each sequence is converted back to its original byte, and the bytes are interpreted as UTF-8 text. The result is the original, human-readable string. Decoding is what happens when your browser displays a search result URL as readable text in the address bar, even though the underlying link contains nothing but ASCII.

How to Use the URL Encoder / Decoder

1. Choose your operation. Select either Encode or Decode depending on what you need. Encoding converts plain text into a percent-encoded format safe for URLs. Decoding reverses that process and returns a percent-encoded string to its original readable form.
2. Paste or type your input. Enter the text, query value, or full URL into the input field. For encoding, paste the raw value you wish to embed inside a URL, such as a search phrase, a file path, or a parameter value. For decoding, paste the encoded string you have received, perhaps copied from a browser address bar, an API response, or a server log.
3. Run the conversion. Click the Encode or Decode button. The tool processes your input instantly and displays the result in the output field.
4. Copy the result. Use the copy button or select all text in the output field. The encoded string is ready to paste directly into a URL, API call, configuration file, or code. The decoded string is ready for human reading, debugging, or further processing.
5. Verify the output. Before using an encoded value in a production URL or API request, check that reserved structural characters you did not intend to encode remain untouched, and that characters which must be encoded have been replaced with their correct %XX sequences.

Why Use This Tool

Constructing percent-encoded strings by hand is tedious and error-prone. The hexadecimal values for common characters are not intuitive, and a single wrong digit produces an invalid or misread URL. A dedicated encoder removes all of that manual arithmetic and guesswork, producing correct output in a fraction of a second.

Beyond convenience, the tool ensures consistency. Different programming languages, frameworks, and libraries implement URL encoding with subtle differences. Some replace spaces with + rather than %20. Some encode characters that others treat as safe. When you need a canonical, RFC-compliant encoding, using a dedicated tool guarantees the result matches the specification rather than the quirks of whichever library your application happens to use.

The decoder is equally valuable for debugging. When a URL arrives in a server log, an API error message, or a browser's network inspector, it is often fully or partially encoded. Reading %E2%80%93 and deducing that it is an en-dash requires knowing UTF-8 byte sequences off by heart. Pasting the string into a decoder gives you the readable form instantly, which makes diagnosing malformed requests, unexpected characters, and encoding mismatches far quicker.

For developers working with third-party APIs, URL encoding is a constant concern. Query parameter values passed to search APIs, mapping services, payment gateways, and authentication endpoints must be encoded correctly, or the receiving server will reject the request or silently misinterpret the data. The tool allows you to verify your encoding before it leaves your development environment, reducing the debugging cycle caused by server-side rejections.

Non-developers benefit as well. Marketers building UTM-tracked links, content managers copying product URLs with special characters, and analysts constructing query strings for reporting tools all encounter URLs that contain characters requiring encoding. This tool removes the need to understand the underlying specification and simply produces the correct output.

Real-World Use Cases

Search engine query strings. A user searching for C++ primer (5th edition) produces the query string ?q=C%2B%2B+primer+%285th+edition%29. The plus signs and parentheses must be encoded, otherwise the server either rejects the request or interprets the plus signs as additional parameter separators. Encoding ensures the full phrase reaches the server intact.

E-commerce product URLs. Products with names like Men's Waterproof Jacket & Hood cannot appear literally in a URL. The apostrophe becomes %27, the ampersand becomes %26, and the spaces become %20 or + depending on context. Shops that auto-generate URLs from product names rely on encoding to prevent broken links.

API requests with compound parameters. REST APIs frequently accept filter values, date ranges, and JSON snippets as query parameters. A date range like 2024-01-01 to 2024-12-31 must be encoded before it can be appended to a URL, because the spaces would terminate the parameter prematurely without encoding. Similarly, a JSON fragment like {"status":"active"} contains curly braces, quotes, and colons that all require encoding.

OAuth and authentication flows. OAuth 2.0 redirect URIs are passed as query parameters within authorisation requests. A redirect URI like https://example.com/callback?source=login must itself be percent-encoded when embedded inside the authorisation URL, because the slashes, colons, and question mark it contains would otherwise break the outer URL's structure.

Email marketing links. UTM parameters in campaign URLs often contain spaces, slashes, and pipe characters as part of campaign names and source identifiers. Encoding these parameters ensures that every tracking click registers correctly in analytics platforms and that no character in the campaign name corrupts the URL structure.

Multilingual and internationalised URLs. A page titled in Arabic, Chinese, or any non-Latin script requires every character to be encoded for transport, even though modern browsers display the decoded form in the address bar for readability. Encoding allows these pages to be linked and shared correctly across all systems, regardless of locale settings.

Debugging server logs. When a request fails, server logs often record the raw percent-encoded URL. Decoding it reveals the original search term, file path, or parameter value that the client sent, which is often the fastest way to identify what went wrong. A 400 Bad Request that looks mysterious in encoded form frequently becomes obvious once decoded.

Web scraping and data extraction. Scrapers that follow pagination links, collect search result URLs, or extract resource paths from HTML attributes regularly encounter percent-encoded strings. Decoding them before storage or comparison prevents duplicate entries caused by the same URL appearing in both encoded and decoded form.

Common Mistakes and Troubleshooting

Double encoding. The most frequent URL encoding bug is encoding an already-encoded string a second time. When %20 is encoded again, the percent sign itself becomes %25, producing %2520. The server then either decodes it to the literal string %20 rather than a space, or rejects the request entirely. The fix is to decode the string first to verify its current state before encoding. Store raw, unencoded values in your data layer and encode them only at the point where you construct the URL.

Encoding the entire URL instead of just the parameter values. A common misunderstanding is feeding a complete URL into an encoder. This converts the slashes, colons, and question marks that give the URL its structure into percent-encoded sequences, producing a string that is no longer a valid URL. Encoding applies to the values within a URL, not the URL's structural characters. Encode each query parameter value individually, then assemble the full URL.

Confusing space encoding conventions. The HTTP specification allows spaces to be encoded as either %20 or + in query strings, but only in query strings, not in path segments. The + convention comes from the HTML form encoding type application/x-www-form-urlencoded. If you copy a query value from one context and paste it into another that expects the other convention, spaces will either be misread or appear as literal plus signs. When in doubt, use %20, which is valid everywhere.

Forgetting to encode the percent sign itself. If your data contains a literal percent sign, for example a discount value of 50%, that percent sign must be encoded as %25. Leaving it unencoded means the server will attempt to interpret whatever follows it as a hexadecimal pair, which produces garbled output or a parsing error.

Mishandling non-ASCII characters. URL encoding for non-ASCII text is a two-step process: the character is first converted to its UTF-8 byte sequence, and then each byte is percent-encoded. A common mistake is encoding non-ASCII characters using a different character set such as Latin-1, which produces different byte sequences and therefore different percent-encoded strings. Always use UTF-8 as the base encoding, which is what all modern browsers and servers expect.

Decoding a URL that was never encoded. Running a decoder over a plain URL that happens to contain a percent sign followed by two hexadecimal digits will corrupt it. For example, sale%off would cause a decoder to attempt to read %of as a percent-encoded sequence, which is invalid, and most decoders will either throw an error or produce unexpected output. Verify that the string you are decoding is actually percent-encoded before running it through a decoder.