URL Encoder / Decoder

**What Is URL Encoding (Percent-Encoding)?** URL encoding — formally called percent-encoding — is the process of converting characters that are not allowed in a URL into a safe format that any web server, browser, or API can read without confusion. Defined in RFC 3986, the standard that governs all Uniform Resource Identifiers, percent-encoding replaces each unsafe character with a percent sign followed by two hexadecimal digits representing the character's ASCII value. A space becomes %20, an ampersand becomes %26, and an equals sign becomes %3D. Every developer who works with HTTP requests, REST APIs, form submissions, or query strings eventually hits a URL encoding problem. A search query with a space breaks a link. A query parameter containing an ampersand gets parsed as two separate parameters. An API key with a plus sign gets silently converted to a space. This free URL encoder and decoder tool solves all of those problems in seconds — no installation, no libraries, no server required. **A Brief History: RFC 1738 to RFC 3986** URL encoding has a history that stretches back to 1994. RFC 1738, published in December 1994, introduced the original URL specification and defined the first encoding rules for unsafe characters. As the web grew more complex — accommodating internationalized content, REST APIs, OAuth flows, and dynamic applications — the standard was refined. RFC 2396 (1998) updated the syntax, and RFC 3986 (2005) replaced it entirely as the current canonical standard for URI syntax. RFC 3986 clarified the distinction between reserved and unreserved characters, formalized percent-encoding for non-ASCII content, and is the spec that all modern browsers, servers, and libraries implement today. Understanding this evolution helps explain why some older systems and libraries behave slightly differently — they may still follow the older RFC 1738 rules, which treated some characters differently. **How to Use This URL Encoder / Decoder** Using the tool is straightforward: 1. **Choose your mode** — Select "Encode" to convert plain text into a URL-safe percent-encoded string, or "Decode" to convert a percent-encoded string back to readable text. 2. **Paste your input** — Enter the text or URL you want to process in the input field. You can paste a full URL, a query string, an individual parameter value, or any arbitrary text. 3. **Click the button** — The tool processes your input instantly in your browser. No data is sent to any server. 4. **Copy the result** — Use the copy button to grab the output and paste it wherever you need it. The tool handles both standard URL encoding (where spaces become %20) and the application/x-www-form-urlencoded variant (where spaces become +). It also supports component mode — decoding a single query parameter value — versus full-URL mode, which preserves structural characters like `://`, `?`, `&`, and `=` untouched. Component mode is what you want when decoding an individual parameter value like `hello%20world%20%26%20more`; full-URL mode is better for decoding a complete URL like `https://example.com/search?q=hello%20world`. **Real-World Encoding Examples** Here are the most common characters you'll encounter and their percent-encoded equivalents: | Character | Meaning | Encoded Form | |-----------|---------|---------------| | Space | Word separator | %20 (or + in forms) | | & | Parameter separator | %26 | | = | Key-value separator | %3D | | # | Fragment identifier | %23 | | + | Often decoded as space | %2B | | / | Path separator | %2F | | ? | Query string start | %3F | | @ | Username in URL | %40 | | : | Port / scheme separator | %3A | | % | Literal percent sign | %25 | For example, encoding the string `hello world & goodbye` produces `hello%20world%20%26%20goodbye`. Encoding a search query like `C++ tutorial` produces `C%2B%2B%20tutorial` — preserving the plus signs as literal characters rather than space substitutes. **Reserved vs. Unreserved Characters (RFC 3986)** RFC 3986 divides URL characters into two categories: **Unreserved characters** — these are always safe and never need encoding: - Uppercase and lowercase letters (A–Z, a–z) - Digits (0–9) - Hyphen (-), period (.), underscore (_), tilde (~) **Reserved characters** — these have special meaning in URLs. They must be encoded when used as data, but left as-is when used for their structural purpose: - `:`, `/`, `?`, `#`, `[`, `]`, `@` — part of the URI structure - `!`, `$`, `&`, `'`, `(`, `)`, `*`, `+`, `,`, `;`, `=` — sub-delimiters When you're building a query string parameter value that contains an `&`, you must encode it as `%26` so the server doesn't interpret it as the start of a new parameter. When you're building the query string structure itself, you leave the `&` as-is to separate parameters. **Encoding and Decoding in JavaScript** JavaScript developers face a common choice between two pairs of built-in functions: **`encodeURI(url)` / `decodeURI(url)`** — encode/decode a full URL. They do NOT touch characters with structural meaning: `: / ? # [ ] @ ! $ & ' ( ) * + , ; =`. Use when you have a complete URL. ```javascript encodeURI("https://example.com/search?q=hello world") // → "https://example.com/search?q=hello%20world" decodeURI("https://example.com/search?q=hello%20world") // → "https://example.com/search?q=hello world" ``` **`encodeURIComponent(value)` / `decodeURIComponent(value)`** — encode/decode a single query parameter or path segment. They encode everything except unreserved characters, including `&`, `=`, `?`, `/`, and `+`. Use on individual values. ```javascript encodeURIComponent("price >= $100 & size=L") // → "price%20%3E%3D%20%24100%20%26%20size%3DL" decodeURIComponent("price%20%3E%3D%20%24100%20%26%20size%3DL") // → "price >= $100 & size=L" ``` The rule of thumb: use `encodeURIComponent` on parameter values, then join them manually with `&`, `=`, and `?`. **Encoding and Decoding in Python, PHP, and Java** In **Python 3**, use `urllib.parse.quote()` for path encoding and `urllib.parse.quote_plus()` for query string encoding (converts spaces to +). To decode, use `unquote()` and `unquote_plus()`: ```python from urllib.parse import quote, unquote, urlencode, unquote_plus quote("hello world") # → 'hello%20world' unquote("hello%20world") # → 'hello world' urlencode({"q": "C++ tips"}) # → 'q=C%2B%2B+tips' unquote_plus("hello+world") # → 'hello world' ``` In **PHP**, use `urlencode()` for encoding query string values and `urldecode()` to reverse it. Use `rawurlencode()` / `rawurldecode()` for path segments (RFC 3986 compliant, encodes spaces as %20 not +): ```php urlencode("hello world & more"); // → 'hello+world+%26+more' urldecode("hello+world+%26+more"); // → 'hello world & more' rawurlencode("hello world"); // → 'hello%20world' ``` In **Java**, use `java.net.URLEncoder` and `java.net.URLDecoder` with explicit UTF-8 charset: ```java import java.net.URLEncoder; import java.net.URLDecoder; import java.nio.charset.StandardCharsets; String encoded = URLEncoder.encode("hello world & more", StandardCharsets.UTF_8); // → "hello+world+%26+more" String decoded = URLDecoder.decode("hello+world+%26+more", StandardCharsets.UTF_8); // → "hello world & more" ``` Note: Java's `URLEncoder` follows the `application/x-www-form-urlencoded` convention (spaces → +), not the RFC 3986 convention (spaces → %20). For strict RFC 3986 path encoding in Java, use `URI.create()` or a library like Apache HttpComponents. In **curl**, pass `-G` with `--data-urlencode` to let curl handle encoding: ```bash curl -G https://api.example.com/search --data-urlencode "q=hello world & more" ``` **Real-World Use Cases** **E-commerce product URLs**: Product pages frequently include filter parameters like `?color=Blue+%26+Black&size=XL`. When parsing these on the server side, you must decode them before comparison — otherwise `"Blue & Black"` (decoded) won't match `"Blue+%26+Black"` (raw). Forgetting to decode before processing filter logic is a common cause of empty search results in e-commerce platforms. **OAuth 2.0 redirect URIs**: When passing your `redirect_uri` as a query parameter to an authorization server (like Google or GitHub OAuth), the entire redirect URI must be percent-encoded — every `?`, `&`, and `=` inside it becomes `%3F`, `%26`, and `%3D`. If you pass `redirect_uri=https://myapp.com/auth/callback?code=true` raw, the authorization server parses `code=true` as a separate top-level parameter, not part of the redirect URI. **Search query handling**: Google and most search engines encode query strings: `https://www.google.com/search?q=C%2B%2B+programming`. When building a search integration, decode the `q` parameter before passing it to your internal search index. Searching for the literal string `C%2B%2B` returns zero results; searching for `C++` returns the relevant documents. **Webhook payloads**: Many webhook services (Stripe, Twilio, GitHub) send URL-encoded POST bodies (`application/x-www-form-urlencoded`). Your endpoint must decode each field value before processing. A Stripe webhook body contains fields like `data%5Bobject%5D%5Bamount%5D=5000` — `data[object][amount]=5000` after decoding. **Common Mistakes and How to Avoid Them** **1. Double-encoding** — The most frequent error. If you encode `hello%20world` again, the % becomes %25 and you get `hello%2520world`. Servers receive `hello world` only on the first decode but `hello%20world` (literally, as text) on the second. Always check whether input is already encoded before encoding again. This tool's decode function will reveal if your string has been double-encoded. **2. Encoding the entire URL instead of parameter values** — If you encode `https://example.com?q=test`, the colon, slashes, and question mark all get encoded and the URL breaks. Only encode individual parameter values, never the structural URL characters. **3. Forgetting to encode + signs** — In query strings, `+` is interpreted as a space by many servers. If you have a literal plus sign (like a C++ version or a phone number like +1-555-0100), it must be encoded as `%2B`. **4. Encoding path slashes** — If your API path includes a resource ID that contains a slash (e.g., a file path like `reports/2024/january`), encoding the slashes as `%2F` may cause the server's router to reject the request. Many web frameworks treat `%2F` differently from `/` in path segments. **5. Missing UTF-8 characters** — Non-ASCII characters (like é, ñ, 中文) must be UTF-8 encoded first, then percent-encoded. The letter é (U+00E9) becomes the two bytes 0xC3 0xA9, encoded as `%C3%A9`. Modern tools handle this automatically, but older systems may not. **Security: Validate Before You Decode** When decoding URL parameters from user input — such as in a web application route handler or API endpoint — always validate and sanitize the decoded value before using it. Raw URL decoding can surface attack payloads: a double-encoded path traversal sequence like `%252F..%252F..%252Fetc%252Fpasswd` decodes first to `%2F..%2F..%2Fetc%2Fpasswd`, then to `/../../../etc/passwd` on a second decode pass. To defend against this: - Decode exactly once, at the entry point of your request handler - Reject strings that still contain `%XX` sequences after a single decode (sign of double-encoding) - Validate against an allowlist after decoding, not before - Use your framework's built-in routing and parameter parsing — it handles decoding safely and consistently - Never decode the same input twice in a processing pipeline **Pro Tips for Developers** **Debugging 400 Bad Request errors**: A malformed URL is one of the most common causes of 400 errors from REST APIs. Use this tool to decode the URL your code is generating and visually inspect whether special characters are properly encoded. Copy the URL from your browser's network tab and paste it here to decode and read the raw parameter values. **Webhook URLs and redirect URIs**: OAuth redirect URIs and webhook callback URLs often contain `?`, `&`, and `=` characters. When you pass a redirect URI as a query parameter to an authorization server, the entire redirect URI value must be encoded — every `?`, `&`, and `=` inside it becomes `%3F`, `%26`, and `%3D`. **API keys and tokens**: If your API key or Bearer token contains `+`, `/`, or `=` (common in Base64-encoded tokens), encode it before placing it in a URL query parameter. These characters have special meaning in URL context and will corrupt the token value if passed raw. **Form data (application/x-www-form-urlencoded)**: HTML form POST data uses the `+` character for spaces instead of `%20`. When reading raw form data, decode it with a form-aware decoder, not a plain URL decoder. Most server frameworks handle this automatically, but if you're manually parsing POST bodies, be aware of the difference. **Testing and Verification** After encoding a URL, verify the result by decoding it and confirming you get back the original string exactly. This round-trip test catches double-encoding, missing characters, and encoding of characters that should have been left as-is. This tool performs all processing in your browser using the Web platform's built-in `encodeURIComponent` and `decodeURIComponent` functions — the same functions your browser uses natively — so the results are always spec-compliant per RFC 3986. For production applications, add URL encoding as a unit test: assert that your URL-building function produces the correct encoded output for a set of known inputs including spaces, special characters, non-ASCII characters, and existing percent signs.