Decode any URL-encoded string back to plain text in one click. Live mode, 50+ character sets, form-encoding handling. 100% browser-based — your data never leaves the page.
Upload a text file to URL-encode or decode it. Files are processed entirely in your browser — nothing is uploaded to a server. Maximum size: 10 MB.
URL encoding (also called percent-encoding) converts characters that aren’t safe in URLs into a %XX hex sequence representing the byte values. It’s defined in RFC 3986, and it’s what lets URLs carry spaces, accented letters, emoji, and reserved characters like & and ? without breaking the URL syntax.
The tool above uses your browser’s native encodeURIComponent and decodeURIComponent under the hood, with extra controls for character set, line-by-line processing, and form-encoded variants.
Drop your URL-encoded string, a full URL, or plain text into the input area.
Decode to read it; encode to make text URL-safe. Live mode runs as you type.
Result appears instantly. Copy with one click, or share via a clean URL.
No. This decoder runs entirely in your browser’s JavaScript. The string you paste, the decoded output, and everything in between stay in your browser tab — nothing is uploaded. You can open DevTools → Network to confirm no request carries your data, or disconnect from the internet and watch it still work. That makes it safe to decode URLs containing tokens, session IDs, or other sensitive values.
Change the Output format selector from “Text” to one of the byte views. “Hex (space-separated)” and “Hex (uppercase, no separator)” show the raw bytes each %XX decodes to; “Hexdump” adds offset and ASCII columns like the Unix hexdump tool; “Bytes summary” reports the byte count and how they map to characters. This is useful when you need to inspect the actual bytes behind a garbled or non-UTF-8 string rather than a rendered character.
Tick “Decode each line separately.” Paste one encoded string per line and each is decoded independently, so a stray character on one line won’t affect the others. It’s the fastest way to batch-decode a column exported from a log file, spreadsheet, or analytics report. All processing still happens in your browser.
A single decode pass peels off one layer. If you see %2520, that’s a space encoded twice (the % of %20 became %25), so it needs two passes. Rather than clicking decode repeatedly, tick “Decode recursively” — it keeps decoding until no %XX sequences remain, up to 16 rounds, handling double- and triple-encoded input in one step.
Garbled output means a character-set mismatch: the bytes were encoded in one charset and you’re decoding with another. Change the Destination character set to match the source. UTF-8 is the modern default and handles most data. For legacy Western European data try Windows-1252 or ISO-8859-1; for old Russian, Windows-1251 or KOI8-R; for old Japanese, Shift_JIS or EUC-JP; for old Chinese, GBK or Big5. The tool supports 50+ charsets, so you can work through the likely candidates for the source region.
On for query strings, off for path components. A + in a form-encoded query string (application/x-www-form-urlencoded) means a space, so leave the option on when decoding query data — the default. In a URL path, a + is a literal plus sign, so turn it off when decoding a path segment, or a real plus in your data will wrongly become a space.
URL decoding — also called percent-decoding — is the reverse of URL encoding, defined in RFC 3986. It takes the %XX hexadecimal sequences in a URL and turns them back into the characters they represent: %20 becomes a space, %3F becomes a question mark, %C3%A9 becomes é. It’s how an encoded, machine-safe URL is turned back into readable text.
No. URL decoding is a reversible format change, not a security operation — anyone can decode a percent-encoded string without a key, so it provides no confidentiality. (“Percent-encoding,” “URL encoding,” and “URL escaping” all refer to this same reversible scheme.) If you need to protect data, that’s what HTTPS and real encryption are for — and sensitive values shouldn’t sit in the URL in the first place.
In JavaScript, decodeURIComponent() throws that error when the input has a broken percent sequence — a % that isn’t followed by two valid hex digits (like abc%2), or bytes that don’t form a valid UTF-8 character. This decoder is more forgiving: it flags the invalid portion instead of crashing, so paste the string here to see exactly where the bad sequence is, then fix the source that produced it.
Yes — attackers sometimes double-encode characters (for example ../ as %252e%252e%252f) to slip path-traversal or injection payloads past a firewall that only inspects the once-decoded form. That’s a defensive reason to decode recursively when reviewing suspicious URLs: tick “Decode recursively” here to fully unwrap nested encoding and see what a string really contains before trusting it. This tool only reveals the decoded value — it never executes anything.
URL decoding is the reverse of URL encoding (also called percent-encoding). It takes a string full of %XX sequences and turns them back into the original characters they represent. A %20 becomes a space, a %3F becomes a question mark, a %E2%9C%93 becomes a check mark (✓). The mechanics are defined in RFC 3986, the URI specification, and every modern browser and language has a built-in function to do it.
You will encounter URL-encoded data in dozens of everyday contexts. Server access logs store the raw URL the client requested, percent-encoded. Analytics tools capture campaign UTM parameters with spaces and punctuation encoded. API responses sometimes include URLs as values in JSON, and those URLs are encoded. Email clients show preview URLs in their original encoded form. Browser address bars often display percent-encoded versions of URLs containing non-ASCII characters or spaces.
Decoding makes these readable. If your log shows ?q=Hello%2C%20World%21, decoding reveals the actual query: ?q=Hello, World!. That changes what you understand about the user’s actual search.
Paste the encoded string into the input box. If “Live mode” is on (it’s on by default), the decoded output appears instantly in the box below. Otherwise, click the Decode button.
Three settings affect the result:
Destination character set. URL encoding represents bytes, not characters. When the bytes get assembled into characters, the decoder needs to know what encoding the original was. UTF-8 is the modern default and handles 99% of real-world data. Legacy systems sometimes use Windows-1252, ISO-8859-1, Shift_JIS (Japanese), or GBK (Chinese). If your output looks like garbled symbols, try changing the character set.
Decode each line separately. Useful when you have a list of encoded strings, one per line — a log file extract, a column copied from a spreadsheet. Each line is decoded independently so a malformed entry doesn’t break the others.
Treat + as space. The form-encoded variant of URL encoding (used in HTML form submissions and query strings sent by browsers) treats + as a space rather than a literal plus sign. Leave this on if your input comes from a form submission or query string; turn it off if you’re decoding path components where + is literal.
Most of the time you want plain decoded text. The other output formats are for debugging:
Hex shows the byte values of the decoded result as space-separated two-digit hex pairs. Useful when the “decoded” text looks wrong and you need to see what bytes you actually got. Hex (uppercase, no separator) is the same data formatted for direct comparison with debugger output. Hexdump is the classic xxd-style three-column view: offset, hex bytes, ASCII rendering. Bytes summary gives a quick at-a-glance read: total length, first 16 bytes, and a guess about whether the content is printable text.
The output has weird symbols like é or â. Character-set mismatch. The bytes were created in one encoding and you’re decoding as another. Try Windows-1252 or ISO-8859-1 for old European data, Shift_JIS for old Japanese data, GBK for Simplified Chinese.
Plus signs in the input become spaces in the output and you didn’t want that. Turn off “Treat + as space.” That setting is on by default because form-encoded data is the most common source of URL-encoded strings, but path components and some other contexts use + literally.
Some characters look right, others look wrong. The input is partially encoded — only some characters were percent-encoded. The decoder still works correctly, but the visual result mixes literal characters from the original with newly-decoded ones. Verify by re-encoding the result and comparing.
The output shows %25XX instead of %XX. Double-encoding. The string was encoded twice. Run the result through the decoder again to peel off the second layer.
Nowhere except your browser. The decoder runs entirely in JavaScript on this page. The URL you paste, the decoded output, and any intermediate state exist only in your browser tab. Open your browser’s DevTools, switch to the Network panel, and you’ll see no requests carrying your URL data — the page loads once, and decoding happens in memory thereafter. Disconnect your network and the decoder still works.
Every control on the decoder maps to a specific behaviour. Here’s what each one does and when to reach for it:
+ as space — on by default. Form-encoded query strings use + for spaces; URL paths treat + as a literal plus. Leave on for query data, turn off for path segments.%XX remain, up to 16 rounds. This is the one-click fix for double-encoded (%2520) and triple-encoded input.All of these run locally in your browser — none of them send your input anywhere. For a deeper walkthrough of specific failure modes, see the URL-encoding troubleshooting guide.
The behaviour of this decoder follows the primary web standards that define percent-encoding. These are the specifications the tool’s handling is built on:
%XX triplet this tool decodes; Section 2.2 lists the reserved characters and Section 2.3 the unreserved set (A–Z a–z 0–9 - _ . ~). Section 2.1 also states that the two hex digits are case-insensitive and that producers should normalize them to uppercase — the basis for the duplicate-URL caveat in our troubleshooting guide. rfc-editor.org/rfc/rfc3986 §2.1application/x-www-form-urlencoded. The living standard that defines the form-encoding variant, where a space is + rather than %20. This is the rule behind the “Treat + as space” option; it is a separate convention from RFC 3986, not part of it. url.spec.whatwg.orgHonest scope: these standards define percent-encoding itself and the form-encoded variant. They don’t govern the legacy single-byte charsets (Windows-1252, Shift_JIS, and the rest) the decoder can also target — those come from their own separate character-set specifications, and the tool applies them only when you select one to recover pre-UTF-8 data.
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.