Enter the text that you wish to encode or decode:
A URL Decoder Encoder converts text between its plain, human-readable form and its percent-encoded form as defined by RFC 3986, the specification that governs how characters are represented inside a URL. When you type a URL into an address bar, only a limited set of characters is technically allowed to appear "as is" — letters, digits, and a handful of punctuation marks. Everything else, from spaces and ampersands to accented letters, emoji, and non-Latin scripts, has to be represented using a percent sign followed by two hexadecimal digits, such as %20 for a space or %3F for a question mark. Encoding is the process of turning readable text into that percent-escaped form so it can travel safely inside a URL. Decoding is the reverse: taking the percent-escaped string and turning it back into readable text.
This tool does both directions in one place. Paste a raw string — a product name with spaces, a search phrase with special characters, a UTM parameter with an ampersand inside it — and it produces the correctly escaped version. Paste an already-encoded URL or query string that looks like a wall of percent signs, and it converts it back into something you can actually read. It is a plain client-side text transformation, not a URL validator, a redirect checker, or a link shortener — it does not fetch the URL, does not check whether the domain resolves, and does not tell you whether the page behind the link actually loads.
URLs were designed in an era when the underlying transport (HTTP headers, early browsers, terminal-based tools) could not reliably handle arbitrary bytes. The URI specification reserves certain characters for structural purposes — ? separates the path from the query string, & separates one query parameter from the next, # marks a fragment, / separates path segments, and so on. If a literal value you want to put into a URL happens to contain one of those characters, the parser reading the URL would misinterpret it as a structural delimiter rather than as part of your data. Percent-encoding solves that by escaping the character's byte value so it passes through untouched until the receiving application deliberately decodes it back.
The same logic applies to characters outside the basic ASCII set. A URL is technically an ASCII-only construct. When you need to represent an accented character, a Cyrillic or Chinese word, or an emoji inside a URL, the text is first converted to its UTF-8 byte sequence, and each byte of that sequence is then percent-encoded individually. That is why a single non-Latin character can expand into two, three, or even four %XX triplets once encoded — each triplet represents one byte of the UTF-8 representation, not one character.
.htaccess file, a spreadsheet of tracking URLs, or a bug report where you need to show a colleague what a garbled link actually says.There is no meaningful "configuration" beyond picking the direction — this is intentionally a single-purpose utility. The value is in speed and reliability: doing this transformation correctly by hand, character by character, is tedious and error-prone, especially with longer strings or non-Latin text.
Anyone building or auditing links runs into percent-encoding sooner or later. A few concrete situations where this tool earns its place in a workflow:
%E2%80%94 sequences.%20 that itself gets encoded into %2520), which breaks the link. Decoding twice and comparing to the original reveals the problem.&, =, or + that would otherwise be parsed as part of the query string structure.One detail that trips people up is that there isn't just one flavor of "URL encoding" — there are a few related but distinct rule sets, and mixing them up produces subtly wrong output.
| Method | What it leaves untouched | Typical use case | Space becomes |
|---|---|---|---|
| Full URI encoding (RFC 3986 percent-encoding) | Unreserved characters: letters, digits, - _ . ~, plus reserved structural characters like / ? # & | Encoding a complete URL where the structural characters should stay intact | %20 |
Component encoding (like JavaScript's encodeURIComponent) | Only the unreserved characters | Encoding a single value that will be inserted into a query string or path segment, where &, =, ? must also be escaped | %20 |
HTML form encoding (application/x-www-form-urlencoded) | Unreserved characters | Data submitted from an HTML form, or the classic "search engine style" query string | + |
The practical consequence: if you decode a query string and a space shows up as a literal plus sign instead of turning into a space, that string was produced with form encoding, not full percent-encoding, and the plus sign needs special handling — a raw + should become a space, not stay as a literal plus, when it's part of a form-encoded query string. Most general-purpose decoders (including this one, when operating on a raw string) treat %2B and a literal + as different things, so it's worth knowing which encoding convention produced the string you're working with before assuming the output is correct.
RFC 3986 splits ASCII characters into a few groups relevant to encoding decisions:
A-Z, a-z, 0-9, and the four symbols - _ . ~. These never need encoding and are safe to leave as-is in any part of a URL.: / ? # [ ] @ ! $ & ' ( ) * + , ; = that carry structural meaning somewhere in a URL. Whether one of these needs encoding depends on where it sits: a / is fine in the path but needs encoding if it's meant to be a literal slash inside a single path segment or query value.©, emoji, non-Latin scripts) always needs encoding, with no exceptions.This is why a full URL and a single parameter value get encoded differently: encoding an entire URL should skip the structural reserved characters so the URL still parses correctly, while encoding one value that's going to be inserted into a query string should escape those same reserved characters, because inside that value they're just data, not structure.
| Character | Percent-encoded | Where it commonly appears |
|---|---|---|
| Space | %20 | Multi-word search phrases, product names, file names |
| & | %26 | A literal ampersand inside a parameter value (not the separator between parameters) |
| ? | %3F | A literal question mark inside a value, e.g. a search query ending in "?" |
| # | %23 | Hashtags, fragment-like text inside a value |
| % | %25 | Any literal percent sign — required so it isn't mistaken for the start of another escape sequence |
| + | %2B | A literal plus sign, distinct from the form-encoding convention where + means space |
| / | %2F | A literal slash inside a single segment, e.g. a date like "2026/07" used as a value |
| @ | %40 | Email addresses or usernames passed as parameter values |
| é, ñ, ü, etc. | Two bytes each, e.g. é → %C3%A9 | Accented characters in non-English content, encoded via their UTF-8 byte sequence |
A detail worth understanding even for non-developers using this tool: percent-encoding operates on bytes, not on "characters" in the everyday sense. Modern text is stored as UTF-8, a variable-length encoding where ASCII characters take one byte and most other characters take two, three, or four bytes. When a URL encoder processes a character outside the ASCII range, it first converts that character to its UTF-8 byte sequence, then represents each individual byte as a %XX triplet. That's why a single Cyrillic or Japanese character can turn into six or nine characters' worth of percent-encoding — you're seeing the raw bytes, not a one-to-one character substitution. It also explains why decoding a percent-encoded URL with the wrong character-set assumption (a legacy tool assuming a different encoding, like Windows-1252, instead of UTF-8) produces garbled mojibake text instead of the original characters — the byte-to-character mapping only works correctly if both the encoder and decoder agree on UTF-8.
& and = as plain characters — encoding the whole assembled string at once will also escape the structural & and = characters, breaking the query string.+ as a space before decoding the rest, since standard percent-decoding alone won't convert it.This tool performs a text transformation only. It does not know whether the resulting URL is a valid, reachable address — that requires actually requesting it, which is outside the scope of an encoder/decoder. It does not validate URL structure (missing protocol, malformed host, illegal character combinations beyond what encoding covers), and it does not distinguish between the different encoding conventions automatically — if a string was produced with form encoding (plus signs for spaces) and you decode it with the assumption of strict RFC 3986 percent-encoding, the plus signs will pass through unchanged rather than becoming spaces, and you'd need to handle that substitution separately. It also won't fix a URL that's broken for reasons unrelated to encoding, such as a wrong domain, an expired certificate, or a server returning a 404. Treat it as one step in a workflow — decode to inspect, encode to build — rather than a full URL-diagnostic tool.
They refer to the same thing. "Percent-encoding," "URL encoding," and "URL escaping" all describe the process of representing unsafe or reserved characters as a percent sign followed by two hexadecimal digits, per RFC 3986.
%20 is the strict RFC 3986 percent-encoding for a space and is correct in any part of a URL. A literal + representing a space is specific to the older application/x-www-form-urlencoded convention used by HTML forms and classic query strings. Both are valid in their respective contexts, but they aren't interchangeable — a decoder needs to know which convention produced the string to convert a + back to a space correctly.
Because encoding works on UTF-8 bytes, not on whole characters. Most non-ASCII characters take two to four bytes in UTF-8, and each byte gets its own %XX triplet, so a single character like "Ă©" becomes two triplets (%C3%A9) rather than one.
Both are valid depending on the goal. Encoding a single parameter value before inserting it into a query string is the safer default, since it escapes structural characters like & and = that would otherwise break the query string. Encoding a complete, already-structured URL should generally be avoided unless you specifically need to escape characters within it, since doing so can unnecessarily encode the slashes, question mark, and ampersands that make the URL work.
The string is likely double-encoded — encoded once, and then that already-encoded output was encoded a second time somewhere in the pipeline (common with CMS exports, redirect scripts, or spreadsheet formulas). Run the decode step again on the output to remove the second layer.
No. It only transforms text between plain and percent-encoded form. It does not send a request, check the HTTP status code, or verify the domain resolves — for that, a redirect checker or an HTTP status tool is the right choice.