How to use URL Encode / Decode
What it does & when you need it
A URL can only safely carry a limited set of characters. The moment a value
contains a space, an ampersand, a slash, a #, or anything non-ASCII, it has to
be percent-encoded — each offending byte rewritten as % followed by two hex
digits — or the request breaks or, worse, silently points somewhere else. This
tool encodes text into that form and decodes it back, entirely in your browser,
so a URL stuffed with API keys, session tokens, or customer identifiers never
leaves your machine.
Reach for it when you're building a query string by hand, debugging why a
redirect drops half its parameters, reading an encoded Location header, or
copying a link out of a log where everything is %3A%2F%2F soup.
How to use
- Choose Encode or Decode with the toggle at the top.
- Pick a Scope: Component (query value) escapes reserved characters too, for a single parameter value or path segment; Full URL leaves the URL structure intact.
- Type or paste into the left buffer, press Sample to load a worked example, or Upload a text file.
- The result appears on the right instantly. Grab it with Copy result or
the
Ctrl/Cmd+Entershortcut. Malformed input in Decode mode shows the exact percent sequence that broke.
Things worth knowing
Component vs. full URL is the choice that trips everyone up. The
component scope uses encodeURIComponent, which escapes almost everything —
including / ? & = # — because those characters are meaningful structure in a
URL and you're encoding a single value that must not be mistaken for structure.
The full URL scope uses encodeURI, which deliberately leaves those reserved
characters alone so an entire address stays clickable. Encode a whole URL with
component scope and the https:// collapses into https%3A%2F%2F; encode a
value with full scope and a stray & in it will split your query string.
A + is not always a space. Under the application/x-www-form-urlencoded
rules that browsers use to submit forms, + decodes to a space. Percent-encoding
proper uses %20 for a space and treats + as a literal plus. This tool follows
the percent-encoding standard: it never turns + into a space and never turns a
space into +. If you paste a form-submitted body and see stray + signs,
that's the form encoding leaking through — decoding it here as-is is correct, but
be aware the two schemes don't mix. Feeding form data through the wrong decoder
double-decodes it.
Reserved vs. unreserved comes from RFC 3986. The standard splits characters
into reserved ones that carry meaning (: / ? # [ ] @ ! $ & ' ( ) * + , ; =)
and unreserved ones that are always safe and are never escaped: A–Z, a–z,
0–9, and - _ . ~. Everything else, including every non-ASCII character, gets
percent-encoded from its UTF-8 bytes — which is why 世 becomes %E4%B8%96
(three bytes, three escapes).
Watch for double-encoding. If a string that's already encoded gets encoded a
second time, every % becomes %25, so a space that was %20 turns into
%2520. That's the classic cause of a link that "works but looks weird" or a
filename that arrives with literal %20 in it. Decode once and inspect: if you
still see % sequences, you had a double-encoded value and should decode again.
For values that will live in JSON, pair this with the JSON formatter; if you're wrangling an existing query string into structured data, query string to JSON is the faster path, and for content bound for HTML rather than a URL, use the HTML entities encoder instead — the escaping rules are different.