Common questions.

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.

Only for the file-upload feature, which is capped at 10 MB — a practical browser ceiling, since very large files can make the tab unresponsive. Typing or pasting text has no fixed limit, though extremely large pastes are processed in memory locally and can slow the tab. For files bigger than 10 MB, a command-line tool is a better fit — 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.

Encoding converts characters that aren’t URL-safe into a % followed by two hex digits (a space becomes %20); decoding reverses that, turning the hex sequences back into readable characters. They’re two directions of the same RFC 3986 scheme.

URLs are limited to a safe subset of ASCII, so spaces, punctuation with structural meaning, and non-English characters must be percent-encoded. Otherwise proxies, gateways, and servers along the way can mis-route or drop the request.

It’s encoding a string that was already encoded, so the % of an existing sequence itself gets encoded — %20 becomes %2520. The receiver then sees a literal %20 instead of a space. Our double-encoding explainer covers the fix.

Decode it more than once — or use our decoder with “Decode recursively” to strip every layer at once. To stop it recurring, make sure raw input is encoded only once, at the point the URL is built.

Percent-encoding hex is case-insensitive (%3a equals %3A), but many caches and crawlers treat URLs as literal strings, so the two forms can be indexed separately and split a page’s authority. Normalizing to one case (uppercase is the RFC preference) avoids that.

No. It’s a reversible formatting step with no secrecy — anyone can decode it instantly. Sensitive data needs HTTPS and real encryption, and shouldn’t sit in the URL in the first place.

You can, but it’s inefficient — percent-encoding can roughly triple the size of binary data. Base64 (about 33% overhead) is the usual choice for binary payloads; see our URL vs Base64 comparison.

Blanket-encoding turns structural characters like :// and / into %3A%2F%2F, so the address is no longer a usable URL and can 404. Encode individual values, then assemble the URL.

Unreserved characters (A–Z a–z 0–9 - _ . ~) never need encoding. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have structural roles and must be encoded when used as data. See our reserved characters reference.

That’s a character-set mismatch — the bytes were produced in one charset (often Windows-1252) but decoded as another (usually UTF-8). Decoding with the correct source charset restores the original text.

Non-ASCII paths use UTF-8 percent-encoding, and search engines decode and display them natively on localized results. Clean, consistent encoding of non-Latin slugs keeps them readable and indexable.

The browser treats # as the start of the client-side fragment, so anything after it is stripped from the request the server (and your analytics) receives. Encode a literal # inside a value as %23 so campaign data survives.

If the tool processes everything client-side, yes — your input stays in the browser tab and is never uploaded. All the tools on this site work that way and keep functioning offline, which you can verify by disconnecting from the network.

The tools handle large inputs comfortably, but extremely large pastes (megabytes of log data) can strain the browser tab since everything is processed in memory locally. For very large jobs, a streaming script is a better fit — see our log-parsing guide.