Twenty-five questions on percent-decoding — from what it is and how to do it in JavaScript, Python, Java, and Go, to fixing garbled text, double-encoding, and the SEO and security side of URL encoding. Need the tool? Open the URL decoder.
URL decoding — also called percent-decoding — is a mechanism defined in RFC 3986 that reverses URL encoding. It reads the %XX hexadecimal sequences in a string and converts them back into the characters they represent: %20 becomes a space, %3F becomes a question mark. It turns a machine-safe URL back into readable text.
HTTP request lines are limited to a safe range of ASCII characters. Special characters, non-English text, and emoji would break that syntax if placed raw into a URL. Encoding converts them into %XX sequences so the data passes cleanly through browsers, proxies, and servers; decoding reverses it on the other end so the original value is recovered.
RFC 3986 sorts characters into two groups. Unreserved characters — A–Z a–z 0–9 - _ . ~ — are always safe and never need encoding. Reserved characters — ? & = : / # and a few others — have structural meaning in a URL, so they must be encoded when they appear inside a value rather than as structure.
No. URL decoding is a fully reversible format change with no secrecy at all — anyone can decode a percent-encoded string without a key. It exists only to let data travel safely inside a URL. For confidentiality, use HTTPS and proper encryption, and keep sensitive values out of the URL entirely.
Yes — “percent-encoding,” “URL encoding,” and “URL escaping” all describe the same reversible scheme. One caveat: JavaScript’s old escape() / unescape() functions are not the same. They are deprecated and produce non-standard %uXXXX sequences for non-ASCII characters, so use encodeURIComponent / decodeURIComponent instead.
You can, but it’s inefficient. Percent-encoding turns each unsafe byte into three characters (%XX), so in the worst case the output is about three times the input size (roughly +200%). For binary payloads, Base64 or Base64URL is cleaner because it only adds about 33% overhead.
Use decodeURIComponent(string) for an individual query value, path segment, or fragment. Use decodeURI(string) only for a complete URL where you want to preserve structural characters like : and /. In most cases decodeURIComponent is what you want.
decodeURIComponent() throws this when it hits a broken percent sequence — a % not followed by two valid hex digits (like abc%2), or bytes that don’t form a valid UTF-8 character. Validate or repair the source string before decoding. Pasting it into our decoder shows where the invalid sequence is instead of crashing.
Use the urllib.parse module. urllib.parse.unquote(string) decodes standard percent-encoding; urllib.parse.unquote_plus(string) also converts + into spaces, which is what you want for form-encoded query strings.
Use java.net.URLDecoder.decode(string, "UTF-8"). Always pass the character encoding explicitly — if you omit it, the platform may fall back to an unpredictable system default and produce garbled output.
Use the net/url package. url.QueryUnescape(string) decodes percent-encoding and converts + to spaces (query semantics); url.PathUnescape(string) decodes without the +-to-space conversion, for path segments.
There’s no single standard SQL function. Approaches vary by engine — PostgreSQL can decode bytes with helpers like convert_from() combined with byte substitution, and many teams write a small user-defined function to sanitize logged URLs. If you’re just inspecting a value, it’s usually simpler to decode it in your application layer or in a tool than inside SQL.
That’s a character-set mismatch: the bytes were encoded in one charset (often Windows-1252 or ISO-8859-1) but you’re decoding them as UTF-8. Pick the correct source charset. Our decoder supports 50+ charsets — try Windows-1252 or ISO-8859-1 for legacy Western data, Shift_JIS for old Japanese, GBK for old Chinese, KOI8-R for old Russian.
Double-encoding is encoding a string that was already encoded, so %20 becomes %2520 (the % itself becomes %25). To read it, decode twice — or tick “Decode recursively” in our decoder, which peels off every layer in one pass. To prevent it, find the code that’s encoding an already-encoded value and remove that second pass.
Because of the form-encoding convention (application/x-www-form-urlencoded), where + means space. If you’re decoding a path segment where + is a literal plus, turn off the “Treat + as space” option before decoding, or your real plus signs will wrongly become spaces.
You encoded the URL’s structure along with its data. Running an encoder over a full URL turns https://example.com/ into https%3A%2F%2Fexample.com%2F, which no server can route. Encode only the individual dynamic values — a single query value or path segment — then assemble the URL around them.
Often a filter or faceted-navigation UI that re-encodes the whole query string on every click. Each pass turns % into %25, so a value balloons (%253A → %25253A → …) until it exceeds the server’s header-size limit. Fix: keep filter state as plain values in memory and rebuild the query string from scratch each time instead of re-encoding the live URL.
Yes. Attackers sometimes double-encode characters — for example ../ as %252e%252e%252f — to slip path-traversal or injection payloads past a firewall that only checks the once-decoded form. When reviewing suspicious URLs, decode recursively to fully unwrap the string and see what it really contains before trusting it. A decoder only reveals the value; it never executes anything.
If navigation code generates endless malformed or nested query strings — for example infinite filter combinations — crawlers can get stuck scanning countless near-duplicate URLs. That wastes crawl budget and slows indexing of your real content. Keep parameters clean and canonical, and block or canonicalize filter permutations.
UTF-8 percent-encoding, which is what Google recommends for non-ASCII URLs. A path like /gemüse should encode as /gem%C3%BCse. UTF-8 keeps international URLs portable and correctly indexed across platforms.
RFC 3986 says the hex digits are case-insensitive, so both decode to the same character — but many servers and analytics tools treat the raw strings as distinct keys. That means /caf%C3%A9 and /caf%c3%a9 can be indexed as two separate pages, splitting link equity. Normalize to one case at your CDN or proxy and set a canonical tag. See our troubleshooting guide for the full fix.
The browser treats # as the start of a fragment and never sends anything after it to the server. An unencoded # in the middle of a campaign or token value means everything after it is dropped, silently stripping your attribution parameters. Encode it as %23 when it’s data, and build query strings with URLSearchParams rather than string concatenation.
It depends whether the tool processes input on a server or locally. urlencodedecode.com decodes entirely in your browser with client-side JavaScript — your input never leaves the tab, and the tool keeps working even if you go offline. That makes it safe for URLs containing tokens or other sensitive values. Always check that any tool you use is client-side before pasting sensitive data.
Ordinary URLs and even long lists decode instantly. Very large inputs — think multi-megabyte log dumps — can slow or freeze a browser tab, since everything runs in memory on your machine. For everyday URLs and batches of them you’ll never hit a limit; for huge files, a command-line tool is a better fit.
For very large files — big server logs or database exports — command-line utilities stream data line by line and aren’t constrained by browser memory. Python’s urllib.parse in a short script, or shell tools, will process files that would overwhelm a browser tab. For interactive, one-off decoding, the browser tool is faster and needs no setup.
The answers above rest on the primary web standards that define percent-encoding, plus the official language documentation for the decode functions named:
application/x-www-form-urlencoded serializer — the +-for-space convention used by HTML forms and URLSearchParams. url.spec.whatwg.orgurllib.parse, Java java.net.URLDecoder, Go net/url, and JavaScript decodeURIComponent (MDN). Each language’s own docs are the authority on its exact behaviour.Honest scope: the SQL and browser-memory notes describe general engine and environment behaviour, not anything fixed by a standard — treat those as practical guidance rather than spec-defined rules. The security answers describe how attackers use encoding; they aren’t an endorsement of any technique.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.