Free URL Encoder & Decoder

What URL encoding is

URLs are only allowed to contain a specific set of ASCII characters — letters, digits, and a few unreserved symbols like -, _, ., and ~. Anything else — spaces, non-Latin letters, special symbols like &, ?, #, or the entire universe of emoji and Unicode — must be percent-encoded before it can appear in a URL. Each character or byte becomes %HH in uppercase hex. A space becomes %20. An ampersand becomes %26. A Chinese character encoded in UTF-8 becomes three or four consecutive percent-encoded bytes. This free URL encoder handles every case, in both component mode (safest, encodes everything) and full-URL mode (preserves structural characters like ://).

How to use the URL encoder

1. Pick your mode — Encode (raw → percent-encoded) or Decode (percent-encoded → raw).
2. Paste your input. For batch processing, put one URL per line — each is processed independently.
3. Choose scope: Component (encodes ?, &, =, / — use for query values) or Full URL (preserves URL structure — use for encoding a whole URL that happens to contain spaces or Unicode).
4. Click Convert →. The result appears below with a success/error summary.
5. Copy or download using the buttons in the result panel.

Component mode vs Full URL mode

Rule of thumb: If you’re encoding the value of a single query parameter, use Component. If you’re encoding an entire URL string that already contains structure, use Full URL.

Which characters need encoding?

The RFC 3986 “unreserved” set never needs encoding: A–Z, a–z, 0–9, and the four characters - _ . ~. Everything else is either “reserved” (has structural meaning in URLs) or unsafe (some ASCII characters break older systems). Every non-ASCII character (accented letters, Cyrillic, Greek, CJK, emoji) must be UTF-8 encoded first, then each resulting byte percent-encoded.

Common use cases

Building query strings

Every value in ?key=value&key2=value2 must be Component-encoded. A search query like “coffee & donuts” becomes ?q=coffee%20%26%20donuts. Without encoding, the & would split the URL into two separate parameters and mangle the request.

Sharing URLs on social media

When you want to prefill a share dialog with a URL, that URL itself needs to be encoded first: https://twitter.com/intent/tweet?url={encoded URL}. If the URL contains query parameters, those must be encoded within the encoded URL — leading to double-encoded strings like %253F (which decodes to %3F, which decodes to ?).

Debugging URLs from logs

Web server logs and analytics tools often show URLs already percent-encoded. Paste them into Decode mode to see the original human-readable value. Great for tracing weird search-term stats or referrer data.

API request formation

REST APIs that accept parameters in the URL require every user-generated value to be Component-encoded. Failing to do so is a common source of API errors and (worse) request-forgery vulnerabilities.

Google/Bing search URLs

Search-engine result URLs are heavily encoded. Decode them to see what someone actually searched, or encode a query to build a custom search URL programmatically.

The + vs %20 question for spaces

In the pre-Unicode era, HTML forms used + to encode a space in query strings. This survives in some places today: PHP’s urlencode() function still uses +, while rawurlencode() uses %20. JavaScript’s encodeURIComponent() always uses %20, which is the modern standard.

Both are technically valid in query strings, but:

• Use %20 everywhere else — path segments, fragments, headers, JSON
• + is only for space in application/x-www-form-urlencoded query strings

Our tool uses %20 consistently, which works everywhere.

URL encoder comparison

Pro tips

• When in doubt, Component mode. Over-encoding is safe — receiving software will decode it. Under-encoding breaks URLs.
• Double-encoding is real and sometimes intended. If a URL flows through multiple systems (redirect → tracking → destination), each layer may add its own encoding. To decode fully, run Decode mode multiple times until nothing changes.
• Encode before you concatenate, not after. Building URLs by string concatenation without encoding user input is one of the top web security vulnerabilities. Always encode each variable individually.
• The # fragment doesn’t get sent to the server. Text after # stays in the browser. But encoding matters if the fragment contains structural characters your JS reads.
• File names in URLs need encoding. A file called Report Final (v2).pdf becomes Report%20Final%20%28v2%29.pdf in a URL.