What percent-encoding is
A URL may only contain a small set of US-ASCII characters. RFC 3986 §2.3 calls the safe ones unreserved — A–Z, a–z, 0–9 and the four marks - . _ ~ — and everything else must be written as a percent sign followed by the two hex digits of each UTF-8 byte. A space becomes %20; "c++" becomes c%2B%2B.
Because the encoding operates on UTF-8 bytes, a non-ASCII character costs several escapes: "한" is three bytes and becomes %ED%95%9C, and "안녕하세요" becomes %EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94. Fifteen escapes for five syllables is correct, not a bug.
The other group, the reserved characters : / ? # [ ] @ ! $ & ' ( ) * + , ; =, are legal but structural. Left alone they delimit parts of the URL; encoded, they are ordinary data. Deciding which of the two you mean is the whole job of the mode switch below.
Component or whole URL: encodeURIComponent vs encodeURI
Component mode (encodeURIComponent) escapes the structural characters as well, so the result is safe to drop into one slot of a URL: a query value, a path segment, a fragment. Whole-URL mode (encodeURI) leaves ; / ? : @ & = + $ , # untouched so an address you already assembled keeps working while its spaces and Korean text get escaped.
Using the wrong one is the single most common URL bug. Run https://example.com/a b through component mode and you get https%3A%2F%2Fexample.com%2Fa%20b — a string that is no longer a link. Run a user-supplied value through whole-URL mode and an & inside it silently splits your query into two parameters.
The tool lists which structural characters your input actually contains, so you can see what the two modes would do differently before choosing. The strict RFC 3986 option additionally escapes ! ' ( ) * , which encodeURIComponent leaves alone — required by OAuth 1.0a signatures and some S3 pre-signed URLs.
Why a space is sometimes + and sometimes %20
Two encodings share the same percent syntax. In application/x-www-form-urlencoded — what an HTML form posts and what URLSearchParams produces — a space is written as +, and a literal plus sign must therefore be escaped as %2B. In a path, a fragment or a header, a space is %20 and + means a plus.
"Treat + as space" is on by default when decoding, which matches URLSearchParams and every server-side form parser. Turn it off when the value is not form data — a base64url token, a chemical formula, a phone number in +82 form — or you will read a plus as a space that was never there.
Double encoding and how to spot it
Encoding an already-encoded value escapes its percent signs: %20 becomes %2520, and %ED%95%9C becomes %25ED%2595%259C. One decode leaves visible %20 in the output, which is the tell-tale sign. The tool detects this and offers a second pass rather than silently decoding twice, because a value that legitimately contains "%20" as text also exists.
The cause is almost always two layers encoding the same value: your code escapes a redirect target and then the HTTP client, a template engine or a proxy escapes the finished URL again. Fix it by encoding exactly once, at the point where the value is placed into the URL — not on both sides.
Taking a URL apart
The inspector parses an absolute URL with the browser’s own WHATWG URL parser and shows protocol, host, port, path, fragment and every query parameter with its raw and decoded value side by side. A parameter whose raw value cannot be decoded is flagged instead of being silently repaired — that is usually where a bug is hiding.
Two structural facts are worth remembering while reading the breakdown. The fragment after # is never sent to the server — it exists only in the browser — so tracking or state that must reach the backend cannot live there. And the host is case-insensitive while the path and query are not, so /Product and /product are different resources.
Edit any decoded value and press Apply — the URL is rebuilt with each key and value encoded exactly once, which is a safer way to change a tracking parameter than editing the escaped string by hand.
When decoding fails or the text comes back broken
A percent sign that is not followed by two hex digits is a hard error, and so is a truncated multi-byte sequence such as %ED%95 — the tool points at the exact position rather than dropping the character. Both usually mean the URL was cut short by a log line, a spreadsheet cell or a chat client.
Percent-decoding assumes UTF-8, as RFC 3986 §2.5 recommends and the WHATWG URL Standard requires. Legacy Korean pages that escaped EUC-KR bytes (%C7%D1 for "한") therefore fail here, and correctly so: those bytes are not valid UTF-8, and a decoder that guessed would hand you plausible-looking mojibake instead of an error.
Non-ASCII domain names follow a different rule entirely: they are converted to Punycode (RFC 3492), so 한국.kr travels as xn--3e0b707e.kr and is never percent-encoded. Percent escapes belong to the path, query and fragment only.
Encoding, safety and privacy
Percent-encoding makes a value structurally safe inside a URL. It does not make it safe inside HTML, SQL or a shell command — each of those needs its own escaping, and treating an encoded URL as sanitised input is how open-redirect and XSS bugs get written. Decode for inspection, escape again for the destination.
Query strings are logged everywhere — by your server, a CDN, a proxy, and in the browser’s history — so tokens and personal data do not belong in them even when correctly encoded. Conversion here happens in this tab; the URLs you paste are not sent anywhere, and your draft stays in this browser’s localStorage until you clear it.