URL Encode / Decode

What Is URL Encoding?

Sarah, a backend developer in Seattle, is building a search API endpoint. A user types "coffee & tea" into a search box. If Sarah passes that string directly into a URL query parameter, the ampersand will split the parameter into two separate values. The server receives "coffee " and " tea" as distinct parameters instead of one search query. URL encoding solves this: "coffee & tea" becomes "coffee%20%26%20tea", and the server decodes it back to the original string without ambiguity.

URL encoding, also known as percent-encoding, converts unsafe characters into a format that can be safely transmitted over the internet. URLs can only contain a limited set of characters defined by RFC 3986. Any character outside the allowed set, such as spaces, special symbols, or non-ASCII characters, must be encoded as a percent sign followed by two hexadecimal digits. This encoding is essential for web forms, query parameters, and any data embedded in URLs. For encoding binary data, try our Base64 Encode / Decode tool.

What This Tool Does

This tool encodes plain text into URL-safe percent-encoded format and decodes percent-encoded strings back to their original form. It uses the standard encodeURIComponent and decodeURIComponent JavaScript functions, which handle the full UTF-8 character set including Unicode characters.

• Encode inputs: Any plain text string, including spaces, symbols, and Unicode characters
• Encode outputs: A percent-encoded string where unsafe characters are represented as %XX
• Decode inputs: A percent-encoded string
• Decode outputs: The original plain text

How the Encoding Works

URL encoding replaces each unsafe character with a percent sign followed by its byte value in hexadecimal. The UTF-8 encoding is used for non-ASCII characters, which may result in multiple percent-encoded bytes for a single character.

Characters that are safe and do not require encoding include alphanumeric characters (A-Z, a-z, 0-9) and a few special characters like hyphen (-), underscore (_), period (.), and tilde (~). All other characters must be percent-encoded. RFC 3986 defines these unreserved characters and the full encoding rules. For generating secure random strings for API keys or passwords, use our Password Generator.

How to Use the Tool

1. Select the URL Encode tab to convert plain text for safe use in URLs
2. Paste or type your text in the input area
3. Click Encode to see the percent-encoded output
4. Use the Copy button to copy the result to your clipboard
5. Switch to the URL Decode tab to convert a percent-encoded string back to plain text
6. Paste the encoded string and click Decode

Example Calculations

Example 1: Sarah from Seattle encodes the search query "coffee & tea" for her API. The space becomes %20, the ampersand becomes %26, and the result is "coffee%20%26%20tea". She tests this in her Postman collection and confirms the server receives the correct single parameter value.

Example 2:Marcus, a frontend developer in Austin, needs to encode the string "price >= $100 & discount < 10%" for a query parameter. Every special character (>=, $, &, <, %) is percent-encoded: "price%20%3E%3D%20%24100%20%26%20discount%20%3C%2010%25". He verifies this with the tool before deploying his code.

Example 3: Priya, a localization engineer in San Francisco, encodes the French string "Café au lait" for an internationalized URL. The é character is encoded as two bytes (C3 A9) in UTF-8, resulting in "Caf%C3%A9%20au%20lait". She confirms the server decodes it correctly regardless of locale settings. For network-related calculations, try our IP Subnet Calculator.

Real World Scenarios

Web Form Submissions

Sarah from Seattle is debugging a form submission where user input containing special characters is breaking the server. When a user submits a web form with special characters, the browser automatically URL-encodes the data before sending it. Sarah uses this tool to manually construct test form data and debug encoding issues when the automatic encoding does not behave as expected. She discovers her JavaScript framework was double-encoding the data.

API Query Parameters

Marcus from Austin is building a REST API that accepts search queries with special characters. A search for "C++ & Python" would break the URL without encoding. He uses this tool to verify that "C%2B%2B%20%26%20Python" is the correct encoded form. URL encoding ensures the API receives the exact value intended, not a malformed request with split parameters.

Redirect URLs and Deep Links

Priya from San Francisco is building a redirect system that passes a target URL as a parameter. The target URL "https://example.com/search?q=hello world" must be encoded as "https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world" before being embedded in the redirect URL. Without encoding, the question mark and ampersand in the target URL would be misinterpreted as part of the redirect URL structure.

Common Mistakes to Avoid

• Encoding the entire URL instead of just the parameters: Only parameter values and path segments containing unsafe characters should be encoded. The URL structure (protocol, domain, slashes, question marks, ampersands) must remain intact. Encoding the slashes in a URL path will break navigation.
• Using encodeURI instead of encodeURIComponent: encodeURI leaves characters like ?, &, and = unencoded because they are part of URL syntax. For parameter values, always use encodeURIComponent. This tool uses encodeURIComponent, which is correct for query parameter values.
• Double-encoding: Encoding an already-encoded string produces incorrect results. "%20" becomes "%2520" because the percent sign itself gets encoded. Always decode first if you are unsure whether a string is already encoded.
• Assuming plus signs are spaces: Some legacy systems use + for spaces (application/x-www-form-urlencoded). Standard URL encoding uses %20. This tool uses %20 as per RFC 3986. If you need + for form data, replace %20 with + after encoding.
• Treating URL encoding as encryption: URL encoding is reversible by anyone and provides zero security. It is purely for safe transmission. Never use it to hide or protect sensitive data. For secure password generation, use our Password Generator.

Limitations of This Tool

This tool uses JavaScript's encodeURIComponent and decodeURIComponent, which follow the RFC 3986 standard for percent-encoding. It does not handle the application/x-www-form-urlencoded encoding scheme (which uses + for spaces) common in HTML form submissions. It does not validate whether the decoded output is valid UTF-8, so decoding a malformed percent-encoded string may produce unexpected results. The tool does not encode full URLs with preserved structural characters; for that, use encodeURI in your own code. It does not handle URL normalization, IDN (internationalized domain name) conversion, or Punycode encoding. For related tools, try our Base64 Encode / Decode, Password Generator, or IP Subnet Calculator.

Authoritative Research and Resources

• RFC 3986: Uniform Resource Identifier (URI): Generic Syntax is the official IETF standard that defines URL syntax, the unreserved character set, and percent-encoding rules. Published in 2005 by Tim Berners-Lee and colleagues, it remains the authoritative specification for URL encoding. Section 2.1 covers percent-encoding, and Section 2.2 defines reserved characters.
• MDN Web Docs: encodeURIComponent() documents the JavaScript function this tool uses for encoding. It explains which characters are encoded, how Unicode characters are handled through UTF-8, and the difference between encodeURIComponent and encodeURI. MDN is maintained by Mozilla and is the standard reference for web platform APIs.
• WHATWG URL Standard is the living standard that browsers follow for URL parsing and serialization. It updates and in some cases supersedes RFC 3986 for web contexts. The WHATWG standard defines how percent-encoding interacts with URL parsing in modern browsers, including handling of query strings and fragments.