Answers to the most-asked questions about URL encoding, percent-encoding, character sets, and our tools.
URL encoding (also called 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.
Any time you put data into a URL that contains spaces, reserved characters (?, &, #, =, /), or non-ASCII characters. Common situations: building query parameter values, constructing redirect URLs with embedded URLs, generating tracking links with arbitrary campaign names, sending form data via GET requests.
%20 is the canonical percent-encoded space and 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.
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.
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.
Double-encoding happens when something gets URL-encoded twice — a %20 becomes %2520, because the % itself gets encoded as %25. You typically see this when one layer of a system encodes input that was already encoded. Fix: decode the string twice.
Yes — the terms are used interchangeably. RFC 3986 uses "percent-encoding" as the official name. JavaScript's old escape() function is different (and obsolete) — it produced %uXXXX sequences for non-ASCII characters that aren't actually valid URLs.
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.
Yes, but Base64 is usually a better choice. URL encoding inflates data by 3× on average (every byte becomes 3 ASCII chars). Base64 inflates only 33%. For embedding binary in URLs, Base64URL (a URL-safe Base64 variant using - and _ instead of + and /) is the standard choice.
UTF-8 (default and recommended), ASCII, all ISO-8859 variants (Latin-1 through Latin-10), Windows code pages (1250–1258), KOI8-R, KOI8-U for Cyrillic, Shift_JIS / EUC-JP / ISO-2022-JP for Japanese, GB18030 / GBK / Big5 for Chinese, EUC-KR / ISO-2022-KR for Korean, and the UTF-16 family.
It's a practical browser ceiling. JavaScript can handle larger files, but the tab becomes unresponsive and large data URIs can crash some browsers. For files larger than 50 MB, use a command-line tool — every operating system has a built-in URL encoder/decoder.
Yes. After the first page load, everything runs in your browser. You can disconnect your network and the encoder/decoder still works. The only requests the page makes are for fonts, analytics, and ads — none of which affect functionality.
Yes — both the URL you type into your address bar (with our tool's URL parameter) and a copy/paste of the encoded output are shareable. The encoder produces standard percent-encoded output that works in any web context.
Yes for the actual encoding/decoding — your input never leaves your browser. The page itself does use Google Analytics for page-view tracking and serves ads to keep the tool free, but those services have no access to what you type into the form. See the privacy policy for full detail and opt-out instructions.