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.
URL encoding (or percent-encoding) is a scheme defined in RFC 3986 that lets URLs carry characters that would otherwise be unsafe or have special meaning. A space becomes %20, a colon becomes %3A, a question mark becomes %3F. Every non-ASCII byte is also percent-encoded so the URL stays inside the ASCII set, which is what HTTP requires for the request line.
Use encodeURIComponent for individual pieces of a URL — a query parameter value, a path segment, or a fragment. It escapes everything that isn’t a letter, digit, or one of - _ . ! ~ * ' ( ). Use encodeURI only when encoding a complete URL where you want to preserve the structural characters (: / ? # [ ] @ & =) — but you almost never want this in practice, because the structural chars in your input might be data, not structure.
You’ve almost certainly got a character-set mismatch. The encoded bytes were created in (say) Windows-1252 and you’re decoding as UTF-8. Switch the destination character set selector to match the source. If you don’t know the source, try Windows-1252 or ISO-8859-1 first; those are the most common legacy alternatives to UTF-8 on the web.
%20 is the canonical percent-encoded space — works everywhere in a URL. + as a space is a legacy convention from HTML form submissions (the application/x-www-form-urlencoded media type). Browsers send form data with + for spaces in query strings, so most server-side frameworks treat them interchangeably. In path components, however, only %20 is recognised as a space — a literal + means a literal plus sign there.
No. URL encoding is a fully-reversible representation change — anyone can decode it without a key. It’s purely a transport format that lets binary or non-ASCII data travel inside an ASCII URL. Encryption requires a key to reverse and protects content from being read. If you need confidentiality, use HTTPS and never put sensitive data in the URL itself.
Double-encoding happens when something gets URL-encoded twice — a %20 becomes %2520, because the % itself gets encoded as %25. You usually see this when one layer of a system encodes input that’s already encoded. Fix: decode the string twice. Our tool returns the result of one decode pass; just run it through again to undo the second layer.
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.