What is URL encoding (percent-encoding)?
A URL may only be written with a small set of ASCII characters. Everything else — spaces,
punctuation with a job to do, and every non-English letter — has to be rewritten before the
link is safe to send. Percent-encoding is that rewrite: take the character, convert it to
bytes (UTF-8 for anything non-ASCII), and write each byte as a % sign followed
by two hexadecimal digits. A space is one byte, so it becomes %20.
é is two UTF-8 bytes, C3 A9, so it becomes %C3%A9.
An emoji is four bytes, so 😀 becomes %F0%9F%98%80. Decoding
reverses the process, one percent sequence at a time. The rule comes from RFC 3986, the
standard that defines what a URI is allowed to contain.
Which characters get encoded?
RFC 3986 splits ASCII into three groups. The unreserved characters —
A–Z, a–z, 0–9, and - . _ ~ — are never
encoded, in any mode. The reserved characters —
: / ? # [ ] @ ! $ & ' ( ) * + , ; = — have a job in a URL's structure:
? starts the query, & separates parameters, #
starts the fragment. Whether they get encoded depends on context: inside a single value they
are data and must be escaped, but in a whole URL they are structure and must be left alone.
That is exactly what the two modes above do. Everything else — spaces, < > " { } | \ ^ `,
control characters, and all non-ASCII text — is encoded in both modes. And the
% sign itself is always encoded as %25, because an unencoded
% would look like the start of an escape.
encodeURI vs encodeURIComponent — a real example
JavaScript has two built-in functions, and picking the wrong one is the most common URL encoding bug on the web. Take this link, where the search term itself contains an ampersand:
https://example.com/search?q=black & white#topencodeURI() encodes the whole URL but keeps its structure characters, so the
link stays a link — the spaces become %20, but the ?,
=, and # survive:
https://example.com/search?q=black%20&%20white#topNotice the trap: the & also survived, so a server reads
q=black%20 and then a second, empty parameter — the search term is silently
cut in half. encodeURI assumes the URL is already correctly structured; it
does not protect a value that contains structure characters.
encodeURIComponent() does the opposite. Applied to the whole URL it escapes
everything, including :// and ?, and the link is destroyed:
https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dblack%20%26%20white%23topThe correct pattern is to encode the value only, then build the URL around it:
encodeURIComponent("black & white") // black%20%26%20white
https://example.com/search?q=black%20%26%20whiteThat is why this tool has two modes: Full URL is encodeURI,
Component is encodeURIComponent. Switch between them on the
same input and watch the breakdown change — it shows exactly which characters each mode
keeps and which it escapes.
When to use each mode
Use Full URL when you paste a complete link that must stay clickable: a
long address copied from an email, a redirect URL you are pasting into a form, a link with
accented characters in the path. Use Component when you are building a URL
from parts: a search term, a product name, a file name, or a whole address that itself goes
inside another URL as a parameter value — for example a redirect_to or
next parameter. If you are ever unsure, component is the safer default for
values, because an unencoded & or = inside a value silently
changes what the server receives.
Mistakes this tool catches
Double encoding. Encoding an already-encoded string turns
%20 into %2520, because the % gets encoded to
%25. It usually happens when a value passes through two layers — a framework
that encodes, then a manual encode on top. Decode once to undo the extra layer, and watch
for this tool's warning when it sees %25 followed by two hex digits.
Encoding a whole URL as a component. https%3A%2F%2F is a
dead link, not an encoded one. If your output starts with https%3A, you picked
the wrong mode — switch to Full URL.
The plus-sign trap. In HTML form data (application/x-www-form-urlencoded),
a space is written as +, not %20 — and a literal plus in the data
must be encoded as %2B. Outside form data, + is just a plus sign.
Decoding a query string with the wrong assumption turns every + into a space
or leaves real spaces as plus signs. This tool uses strict RFC 3986 rules: spaces are
%20, and + stays a plus.
Assuming encoding is security. Percent-encoding hides nothing — anyone can decode it in one step — and it does not make a link safe. A decoded address can still point to a phishing page. Encoding is a transport format, not a cipher.
Honest limitations
Encoding is not encryption
Anyone can decode %20 back to a space. Never encode a password, token, or
secret and treat it as hidden — browsers, proxies, and server logs store the full URL.
Domains are a different system
A domain with accents, like café.shop, is not percent-encoded — it is
converted to punycode (xn--caf-dma.shop). This tool encodes text and URL
parts, not hostnames.
Invalid sequences are rejected, not guessed
A lone %, %2, or %GG is not a valid escape, and
%FF is not valid UTF-8. The tool reports the exact position instead of
silently dropping the character or guessing what you meant.
Decoding does not make a link safe
Decoding only reveals what an encoded link says. Check the destination domain before you open it — especially links from emails, logs, or analytics exports.