Free Online URL Encoder & Decoder

Every time you search Google, submit a web form, or click a link containing a special character, URL encoding is working behind the scenes to ensure the data reaches its destination intact. URL encoding — also called percent-encoding — is the mechanism by which characters that have special meaning in a URL, or characters that are not safe to transmit in a URL, are converted into a standardized format that all HTTP clients and servers can interpret correctly. Understanding it is essential for any developer working with web APIs, query strings, or link generation.

What Is URL Encoding?

A URL is composed of several components: a scheme (https://), a host (example.com), a path (/search), and optionally a query string (?q=hello+world) and fragment (#section). Each of these components has a defined set of characters that are safe to include without modification — the "unreserved" characters: letters, digits, hyphens, underscores, periods, and tildes. Any character outside this safe set, including spaces, ampersands, equals signs, and non-ASCII characters, must be encoded before being placed in a URL.

URL encoding works by replacing each unsafe character with a percent sign followed by the two-digit hexadecimal representation of the character's byte value in UTF-8. A space becomes %20, an ampersand becomes %26, and a forward slash becomes %2F. Non-ASCII characters like accented letters or emoji require multiple bytes in UTF-8, so they expand to multiple percent-encoded sequences. For example, the euro sign € encodes to %E2%82%AC — three bytes, nine characters in the encoded form.

Why Special Characters Break URLs

URLs have a strict syntax defined in RFC 3986, and certain characters serve as delimiters within that syntax. The question mark (?) separates the path from the query string. The ampersand (&) separates individual query parameters. The equals sign (=) separates parameter names from their values. The hash (#) marks the start of a fragment. If any of these delimiter characters appear as data within a URL component — say, if a search query contains an ampersand — the parser will misinterpret them as structural delimiters, breaking the URL into incorrect components.

Consider a search for the query "cats & dogs". If you embed this literally in a URL as ?q=cats & dogs, the parser sees two parameters: q=cats and dogs (the latter with no value). The intended query is lost and the application receives incorrect input. With proper URL encoding, the query becomes ?q=cats%20%26%20dogs, which the parser correctly interprets as a single parameter with the value "cats & dogs". This distinction is not pedantic — it directly determines whether data arrives at its destination correctly.

Percent-Encoding and RFC 3986

The current URL specification, RFC 3986, defines two categories of characters. Reserved characters — such as /, ?, #, &, and = — have syntactic roles in URL structure and must be encoded when they appear as data. Unreserved characters — letters, digits, -, _, ., and ~ — can appear unencoded anywhere in a URL. Everything else must be percent-encoded. RFC 3986 superseded the older RFC 2396 and brought more precise rules about which characters are safe in which URL components, resolving ambiguities that had caused interoperability issues between different HTTP implementations.

It is important to distinguish between encoding a full URL and encoding a URL component. When you encode an entire URL, the structural delimiters like ://, ?, and # should remain as-is, since they define the URL structure. When you encode a component — a query parameter value, a path segment, or a fragment identifier — you encode all reserved characters within that component, since they have no structural role there. Using the wrong encoding scope is a common bug: encoding a full URL with encodeURIComponent() in JavaScript, for example, destroys the URL structure by encoding the colons and slashes.

Practical Use Cases for URL Encoding

URL encoding is required wherever user-supplied or programmatically generated data is inserted into a URL. Search engines that encode query terms, e-commerce sites that include product names in URLs, social platforms that embed user-generated text in share links, and APIs that accept dynamic path or query parameters all depend on correct URL encoding to function reliably. Failing to encode user input before inserting it into a URL can also create security vulnerabilities — an attacker who controls a URL parameter might inject additional parameters or redirect users to unexpected endpoints.

Building API clients is one of the most common contexts where URL encoding matters for developers. When constructing query strings programmatically, each parameter name and value must be individually encoded before being joined with & separators. Most HTTP client libraries provide a utility for this — URLSearchParams in browsers, urllib.parse.urlencode() in Python, HttpUtility.UrlEncode in .NET — but understanding what these functions do helps you debug issues when they behave unexpectedly or when you need to encode data for a context these libraries do not cover.

Common URL Encoding Mistakes to Avoid

Double-encoding is one of the most common URL encoding mistakes. It occurs when already-encoded data is encoded again, turning %20 into %2520 (where % becomes %25). This happens when a developer encodes data before passing it to a library that also encodes it, or when a server decodes a URL and then re-encodes it before passing it to another system. The result is that the receiving end sees literal %20 in the data instead of a space, because only one layer of encoding has been removed. Always verify that encoding happens exactly once at the correct point in the data flow.

Another frequent mistake is assuming that URL encoding and HTML encoding are the same thing. They are not. HTML encoding converts characters to HTML entities — an ampersand becomes & — to prevent them from being interpreted as HTML markup. URL encoding converts characters to percent sequences for safe transmission in URLs. Mixing them up leads to double-escaped values, corrupted data in query strings, or security vulnerabilities. When building links in HTML templates, apply URL encoding to the URL value first, then HTML-encode the result for safe insertion into an HTML attribute — and use your framework's built-in escaping to handle this automatically whenever possible.