A precision tool for percent-encoded data

The URL decoder & encoder, built right. Free, fast, and standards-compliant.

The free online URL decoder for query strings, paths, form data, and anything else percent-encoded. Decode any URL-encoded string to plain text instantly — live mode, 50+ character sets, form-encoding variants, line-by-line decoding. The URL encoder works the same way: paste text, get clean percent-encoded output. Everything runs in your browser — your data never leaves the page.

100% client-side Live mode 50+ charsets RFC 3986 compliant Mobile-friendly
URL Decoder
Stats
0chars
Paste something to see live stats.
Input length0
Output length0
Encoded chars0
Detected
StatusIdle
File encode & decode

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.

Drop a file here
or click to browse · max 10 MB
% The percent sign starts every encoding
50+ character encodings supported
0 bytes leave your browser
100% free, forever
How it works

From %20 to space, in a heartbeat.

What URL encoding actually does

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.

01

Paste

Drop your URL-encoded string, a full URL, or plain text into the input area.

02

Pick a mode

Decode to read it; encode to make text URL-safe. Live mode runs as you type.

03

Read or copy

Result appears instantly. Copy with one click, or share via a clean URL.

More tools

Everything in the toolkit.

Frequently asked

About URL encoding.

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.