What Is URL Encoding (Percent-Encoding)?
URL encoding, formally percent encoding, replaces characters that are unsafe or ambiguous inside a URL with a "%" followed by their two-digit hexadecimal byte value, so the URL can be transmitted and parsed correctly by every browser, server, and proxy in between. It is not encryption or obfuscation: percent-encoding is fully reversible by anyone, with no key involved. This tool works as a url encoder decoder, a url encode online utility, in both directions: paste any text to encode url string values instantly, or paste an already-encoded string to url decode it back to its original form, entirely in your browser. It encodes and decodes for URL transport only: it does not sanitize input against SQL injection or cross-site scripting, and percent-encoding a value never substitutes for proper SQL or HTML escaping at the point that value is actually used, nor does it handle internationalized domain names, since encoding a Unicode hostname is not the same as Punycode/IDN conversion. Nothing typed here is uploaded or retained; encoding and decoding happen entirely in your browser tab.
How URL Encoding Works (RFC 3986), and Its Three Modes
Percent-encoding is defined by RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax," which splits every character into one of three groups. Unreserved characters are always safe and never need encoding. Reserved characters carry structural meaning in a URL and only need encoding when they appear as literal data rather than a delimiter. Everything else (spaces, non-ASCII text, and a handful of other symbols) must always be percent-encoded. Non-ASCII characters are first converted to their UTF-8 byte sequence, and each individual byte is then percent-encoded, which is why a single accented letter or emoji expands into two or more %XX groups.
| Character class | Examples | Encoding rule |
|---|---|---|
| Unreserved | A–Z a–z 0–9 - _ . ~ | Never encoded |
| Reserved | : / ? # [ ] @ ! $ & ' ( ) * + , ; = | Encoded only when used as literal data, not as a delimiter |
| Everything else | Space, é, 中, 😀 | Always percent-encoded as UTF-8 bytes |
Component, Full URL, and Form Encoding: What's the Difference?
These three modes exist because "encode this for a URL" means different things depending on whether you're encoding one value or an entire address. Component mode (JavaScript's encodeURIComponent) encodes everything except unreserved characters, including "&", "=", and "#", making it the correct choice for a single query parameter value. Full URL mode (encodeURI) assumes the input is already a complete URL and leaves those same structural characters untouched so the address doesn't get mangled. Form mode follows the HTML "application/x-www-form-urlencoded" convention used by HTML forms and many API bodies, where a space becomes "+" instead of "%20," a distinction that causes a large share of real-world encoding bugs.
| Mode | Space becomes | Encodes & = ? # | Use for |
|---|---|---|---|
| Component | %20 | Yes | A single query param or path segment value |
| Full URL | %20 | No, preserved | An entire, already-structured URL |
| Form | + | Yes | HTML form submissions, x-www-form-urlencoded bodies |
encodeURIComponent vs. encodeURI vs. escape(): Comparison
JavaScript exposes several encoding functions, and only two of them are still recommended. The encodeURIComponent vs encodeURI question comes up constantly: encodeURIComponent encodes everything except unreserved characters, while encodeURI leaves URL structure characters alone. escape() and unescape() are deprecated since ES3/ES5: they don't correctly UTF-8-encode characters outside the Basic Multilingual Plane, so they mangle emoji and many non-Latin scripts. This tool includes escape() output for legacy debugging only, never use it in new code.
| Function | Encodes & = ? # / | Correct UTF-8 handling | Status |
|---|---|---|---|
| encodeURIComponent | Yes | Yes | Current, use for single values |
| encodeURI | No (preserves structure) | Yes | Current, use for full URLs |
| escape() | Partially, inconsistently | No, breaks on astral-plane characters | Deprecated, legacy only |
Common URL Encoding Errors and What They Mean
Most URL encoding problems come from mixing up which of the three modes applies, or from encoding a value that was already encoded. This tool surfaces the browser's own decode errors directly rather than masking them, so the cause is visible instead of a generic failure. A decodeURIComponent or decodeURI call throws a uri malformed error (URIError: URI malformed) when the input contains a "%" that isn't followed by two valid hexadecimal digits, such as a lone "%," or something like "100% off" where the "%" is meant literally, the fix is to percent-encode that literal "%" as "%25" before decoding. Double encoding url values happens when encoding a string that's already percent-encoded, producing double-encoded output: the "%" in "%20" gets encoded again into "%25," turning "%20" into "%2520," a genuine, common bug caught by decoding once and checking whether the result still contains "%XX" sequences. Finally, a "+" decodes to a literal plus sign under decodeURIComponent, not a space; it only means space inside form-encoded data, so decoding a form-encoded value with the wrong function leaves stray "+" characters in place of spaces, fixed by replacing "+" with a space first or using the matching Form mode.