URL Encoder & Query Parser

Understanding Percent-Encoding

URIs restrict the character set allowed in resource links to a small group of safe ASCII characters. Any characters outside this set must be converted using percent-encoding (also known as URL encoding). This process converts non-ASCII characters and reserved delimiters into a percent sign (%) followed by their hexadecimal value. This utility handles these conversions, helping you format URL parameters, path segments, and query values correctly.

Percent-encoding exists because URLs are defined by standards (RFC 3986) that specify exactly which characters are permitted without encoding. The unreserved characters include uppercase and lowercase letters (A-Z, a-z), digits (0-9), and a limited set of punctuation marks (hyphen, period, underscore, tilde). All other characters, including spaces, must be percent-encoded to ensure that URLs are parsed correctly by servers, proxies, and browsers regardless of the system or programming language processing them.

The encoding process is straightforward. Each byte of the character (or byte sequence for multi-byte characters like those in UTF-8) is replaced by a percent sign followed by two uppercase hexadecimal digits. For example, a space character (ASCII byte value 32, which is hex 20) becomes %20. The letter "" (UTF-8 bytes C3 A9) becomes %C3%A9. The decoder reverses this process, replacing each percent-encoded sequence with the original character.

Encoding Types Explained

• encodeURI: Encodes values while keeping structural URL characters (like http://, ?, &, and =) intact. Used to sanitize a full URL path. This function is designed for encoding complete URIs where the structural components should remain readable. It does not encode characters that have special meaning in a URL, such as the forward slash (/), question mark (?), ampersand (&), equals sign (=), colon (:), and at sign (@). Use encodeURI when you have a complete URL string and want to encode only the parts that are not part of the URL structure.
• encodeURIComponent: Encodes all reserved characters, including delimiters. This is the correct choice for sanitizing parameters to be appended to a query string. Unlike encodeURI, this function encodes all characters except letters, digits, and the characters - _ . ~ ! * ' ( ). This means it encodes characters like /, ?, &, =, and :, which are significant in URL structure. Use encodeURIComponent when encoding a value that will be placed inside a URL parameter, such as a search query or a value in a key-value pair.

The distinction between these two encoding functions is a common source of bugs in web applications. Using encodeURI when you need encodeURIComponent can result in broken URLs because the structural characters in your parameter value are not encoded and interfere with the URL parser. Conversely, using encodeURIComponent on a complete URL encodes the structural delimiters, breaking the URL entirely. This tool lets you switch between these modes to see the difference and choose the correct one for your situation.

URL Parsing and Query Parameter Editing

Beyond simple encoding and decoding, this tool provides a full URL parser that breaks any URL into its component parts: protocol (scheme), hostname, pathname, hash fragment, and individual query parameters. When you paste a URL into the parser, the tool identifies each component and displays them in separate editable fields. You can modify any component, add or remove query parameters, toggle parameters on and off, and see the reconstructed URL update in real time.

This interactive editing is particularly useful when debugging API calls, constructing OAuth redirect URLs, or building complex query strings with multiple parameters. Rather than manually concatenating strings and risking encoding errors, you can visually edit each parameter and let the tool handle the encoding correctly. The parser also validates the URL structure and alerts you if the format is invalid, preventing broken URLs from reaching your application.

Practical Use Cases for URL Encoding

API integrations are one of the most common use cases for URL encoding. REST APIs frequently require parameters to be properly encoded in query strings. When passing user input as a query parameter (like a search term containing spaces or special characters), the value must be encoded to prevent the server from misinterpreting the URL structure. For example, a search for "hello world" must encode the space as %20 or + to prevent it from being parsed as two separate parameters.

Form submissions using the GET method automatically encode form data into the URL. Understanding this encoding helps developers debug form behavior and implement custom form handling. When you see URL-encoded data in browser developer tools or server logs, knowing how to decode it helps you understand what data was actually submitted.

OAuth and authentication flows often require redirect URLs to be precisely encoded. A single incorrectly encoded character in a redirect_uri parameter can cause authentication failures that are difficult to diagnose. Using a reliable encoder ensures that these critical URLs are formatted correctly.

Web scraping and crawling often encounter URLs that contain encoded data. Being able to quickly decode URL parameters helps you understand the data structures used by target websites and construct valid requests for your scraper.

Handling Special Characters and Unicode

Non-ASCII characters (like accented letters, non-Latin scripts, and emoji) require special handling in URL encoding. These characters are first converted to their UTF-8 byte representation, and then each byte is percent-encoded individually. For example, the Chinese character "?" has the UTF-8 byte sequence E4 BD A0, which encodes to %E4%BD%A0 in a URL. The Japanese hiragana "?" (E3 81 82) encodes to %E3%81%82.

This tool handles Unicode encoding and decoding correctly, including multi-byte sequences, combining characters, and characters from the Basic Multilingual Plane and supplementary planes. Whether you are working with Latin accented characters (like , ), Cyrillic, Arabic, Chinese, Japanese, Korean, or emoji, the encoder produces correct percent-encoded output and the decoder correctly reconstructs the original Unicode text.

Comparison with Other URL Encoding Tools

Browser developer tools include encoding and decoding functions in their JavaScript consoles (encodeURI(), decodeURIComponent()), but these require typing commands and offer no visual editing interface. Online encoding tools exist but typically only handle simple text encoding without URL parsing or parameter editing capabilities.

Desktop applications and IDE plugins for URL encoding are available but require installation and are tied to specific development environments. This browser-based tool provides comparable functionality with a graphical interface that works on any device, requires no installation, and runs entirely locally for maximum privacy.

The combination of URL parsing, parameter editing, and percent-encoding in a single tool is uncommon. Most encoding tools only handle the text encoding aspect, leaving you to manually parse and reconstruct URLs. This tool's integrated approach saves time and reduces errors when working with complex URLs that have multiple parameters, nested encoded values, or non-ASCII characters.

Tips and Best Practices

Always use encodeURIComponent for individual parameter values, not encodeURI. This is the most common URL encoding mistake. If you are building a URL by concatenating parts, encode each parameter value separately before joining them with & separators. This ensures that special characters in values do not interfere with the URL structure.

Be aware that the space character can be encoded as either %20 (RFC 3986 standard) or + (form data convention). The + encoding is only valid in the query string portion of a URL and specifically in the application/x-www-form-urlencoded format used by HTML forms. For other parts of the URL, spaces should always be encoded as %20. This tool lets you choose between these two space encoding modes.

When copying encoded URLs, be careful with line breaks and whitespace that may be introduced during copy-paste operations. Some text editors and messaging applications automatically insert line breaks in long URLs, which can break the encoding. Always verify that the encoded string is intact before using it.

For maximum compatibility, limit your URL parameters to unreserved characters (letters, digits, hyphens, underscores, periods, and tildes) when possible. This minimizes the need for encoding and makes URLs more readable in server logs, browser history, and documentation. Reserve percent-encoding for characters that truly cannot be represented as unreserved characters.

URL Encoding Standards and Specifications

Percent-encoding is formally defined in RFC 3986, published by the Internet Engineering Task Force (IETF). This standard replaced the earlier RFC 2396 and established the definitive rules for how characters in URIs must be represented using only ASCII characters. The specification defines three character sets: unreserved characters (which must not be encoded), reserved characters (which have structural meaning in URLs), and excluded characters (which are not part of the URI character set at all).

Unreserved characters include A-Z, a-z, 0-9, hyphen (-), period (.), underscore (_), and tilde (~). These characters are always safe to use in any part of a URL without encoding. Reserved characters include the delimiters that define URL structure, such as the colon (:), forward slash (/), question mark (?), ampersand (&), equals sign (=), plus sign (+), at sign (@), and hash (#). When reserved characters appear outside their intended structural role, they must be percent-encoded to avoid misinterpretation by URL parsers.

Another related standard is RFC 3987, which extends URI handling to include Internationalized Resource Identifiers (IRIs). IRIs allow characters from non-ASCII scripts directly in URIs, but browsers and servers typically convert them to percent-encoded UTF-8 before transmission. Understanding these standards helps developers make informed decisions about when and how to encode data in URLs, and why certain characters behave differently depending on their position in the URL structure.

Common URL Encoding Pitfalls

One of the most frequent mistakes is encoding the entire URL with encodeURIComponent instead of encoding only the parameter values. This encodes structural delimiters like the forward slash and question mark, producing a broken URL that no server can parse. The reverse mistake is equally problematic: using encodeURI on individual parameter values leaves reserved characters like & and = unencoded, which can cause the server to misinterpret the query string structure.

Another common issue is double-encoding. This occurs when a developer encodes a string that is already percent-encoded, turning %20 into %2520. Double-encoding typically happens in pipelines where data passes through multiple encoding steps or when a URL is encoded once by a client library and again by the application code. Always verify whether the input is already encoded before applying another round of encoding.

Developers also frequently overlook the difference between space encoding conventions. In the application/x-www-form-urlencoded format used by HTML form submissions, spaces are encoded as + characters. In all other URI contexts, spaces must be encoded as %20. Using the wrong convention in the wrong context leads to servers receiving literal plus signs or literal spaces instead of the intended space character. This tool's space encoding toggle directly addresses this distinction.

Encoding in> Modern API Development

( Modern REST and GraphQL APIs rely heavily on URL encoding for query parameters, path segments, and OAuth tokens. API documentation tools like Swagger and Postman automatically handle encoding, but developers building custom clients, SDKs, or webhook integrations must encode parameters manually. Failing to encode a parameter containing user-generated content can result in 400 Bad Request errors, parameter injection vulnerabilities, or silent data corruption where only part of the value is received by the server.

Authentication flows, particularly OAuth 2.0, require strict encoding of redirect URIs, state parameters, and code verifier strings. A single unencoded character in a redirect_uri can cause the entire authentication flow to fail, and the resulting error messages often provide little diagnostic information. PKCE (Proof Key for Code Exchange) flows require a code_verifier that must be base64url-encoded without padding, which is a different encoding scheme from percent-encoding but is equally important to get right.

Webhook implementations must encode callback URLs that may contain paths, query parameters, and custom headers. When registering a webhook with a third-party service, the entire callback URL must be properly percent-encoded in the request body or header. This tool helps developers verify their webhook URLs are correctly formatted before registering them, preventing failed deliveries and hard-to-debug integration issues.

Frequently Asked Questions