Skip to main content

URL Encoder

What it does

The URL Encoder converts text to and from percent-encoded form, and it sits alongside the other utilities in our Developer Suite. Edit the decoded pane and the encoded pane updates; edit the encoded pane and the decoded pane updates. Two modes control the encoding strictness. Component mode escapes everything except letters, digits, and the small set -_.!~*'(), which suits individual query values and path segments. Full URL mode leaves URL structural characters (/, ?, #, &, =) intact, which suits encoding an entire URL where those characters need to remain readable.

Common situations

You’re constructing a URL with user-generated content as a parameter: a search query, a free-text comment, an email address. Without encoding, special characters break the URL parser. Encoding the value preserves the original meaning and prevents the URL from being misread.

You’re debugging a URL that arrived in a log or HTTP request and contains a mix of %20, +, and unencoded characters. Decoding it once shows the human-readable form. If %2F is still present after one decode, the value was double-encoded somewhere upstream, a common bug when intermediate services re-encode values that were already encoded.

You’re integrating with an OAuth flow that requires the redirect URL to be encoded before being passed as a query parameter. The redirect URL itself contains query parameters, and nesting them requires encoding the inner URL so its query separators don’t collide with the outer URL’s.

You’re building tracking links with UTM parameters that include spaces or punctuation in the campaign name. utm_campaign=2026 spring launch breaks; utm_campaign=2026%20spring%20launch works. Encoding the value is the routine fix.

You’re producing a URL list for a marketing campaign and want to verify each one decodes to the intended target. Pasting the encoded form here and reading the decoded version catches typos before the URLs reach print or out-of-home advertising.

What you need to know

encodeURIComponent and decodeURIComponent are the JavaScript primitives that handle Component mode; encodeURI and decodeURI handle Full URL mode. The difference is which characters they escape.

Component mode encodes 16 reserved URL characters that appear inside parameter values: ;, ,, /, ?, :, @, &, =, +, $, #, plus space and others. The output is safe to drop into any part of a URL.

Full URL mode encodes only the truly illegal characters (spaces, controls, non-ASCII), leaving structural characters alone so the URL remains readable as a URL.

A trap worth knowing: encodeURIComponent does not encode +, but query-string parsing in many systems treats + as a space. If your encoded value contains a literal plus sign, some receivers will silently turn it into a space. The safe move is to also replace + with %2B after encoding. The tool does not do this automatically, because Component mode follows the spec, and the spec leaves + untouched.

Percent-encoding uses % followed by two hex digits representing the byte value. Space becomes %20. Plus sign becomes %2B. Forward slash becomes %2F. The byte representation is UTF-8 for non-ASCII characters, which is why é becomes %C3%A9 (two bytes) and emoji can become four bytes.

Hash fragments (#anchor) follow the same encoding rules, but most browsers treat them more loosely. Encoding the fragment is safer when generating links programmatically.

The + for space convention comes from form encoding (application/x-www-form-urlencoded), not URL encoding proper. Some systems use +, some use %20. Both decode to a space; they are not interchangeable in encoded form. When in doubt, use %20, which is universally understood.

Double-encoding is a bug pattern: a value gets encoded once, passes through a service, gets encoded again. %20 becomes %2520 (the % itself is encoded). Decoding twice recovers the original. If you see %2520 in a URL, something in the pipeline is re-encoding without checking.

Frequently asked questions

What does URL encoding do?

Replaces special characters with percent-encoded representations so they can appear inside a URL without breaking its structure. space becomes %20, & becomes %26, etc.

When should I use URL encoding?

Whenever a string with special characters or whitespace needs to live inside a URL: query parameter values, path segments containing arbitrary text, redirect URLs nested inside other URLs.

What’s the difference between encodeURI and encodeURIComponent?

encodeURI leaves URL structural characters (:/?#&=) intact; encodeURIComponent escapes them. Use encodeURI for whole URLs, encodeURIComponent for individual parameter values.

Why does my URL contain + instead of %20?

Form encoding (application/x-www-form-urlencoded) uses + for space. URL encoding proper uses %20. Both decode to space, but they are not interchangeable as encoded forms. The receiving system’s interpretation matters.

What’s a percent-encoded character?

% followed by two hex digits representing the byte value. %20 is byte 0x20, which is ASCII space. Multi-byte characters use multiple percent-encoded sequences (one per UTF-8 byte).

Why does my URL have %2520 in it?

Double-encoding. The original value was %20 (encoded once); something encoded it again, turning the % into %25. The fix is to decode twice, or fix the upstream pipeline that’s re-encoding.

Do I need to encode all special characters?

Only the ones that have special meaning in URLs. Letters, digits, and a small set of punctuation (-_.!~*'()) are safe in all positions. Everything else needs encoding when it appears in a context where it has structural meaning.

Should hash fragments be encoded?

Yes, but most browsers tolerate unencoded fragments. Encoding them is safer when generating links programmatically, because it produces predictable behaviour.

Common problems

Problem: Server returns 400 Bad Request on URLs with non-ASCII characters.

The non-ASCII characters were not encoded. Pre-encode them via Component mode before constructing the URL. Most server frameworks tolerate UTF-8 in URLs, but some strict ones (especially older gateways) reject without encoding.

Problem: A + in my encoded URL is being interpreted as a space.

The receiving system uses form encoding, where + means space. To preserve a literal +, encode it as %2B explicitly. Most URL encoders do not do this by default because the URL spec proper says + is fine literal.

Problem: Decoding produces “URI malformed” error.

The encoded string contains an invalid percent sequence, usually % not followed by two hex digits, or a truncated multi-byte UTF-8 sequence. Check the encoded string for % characters that aren’t followed by two valid hex digits.

Problem: Encoded URL works in Chrome but fails in Safari.

Some older Safari versions handle non-ASCII in URLs differently. Always encode non-ASCII characters explicitly (don’t rely on browser tolerance) for cross-browser reliability.

Problem: URLs with encoded slashes (%2F) get decoded by the server.

Some servers automatically decode %2F in path segments, treating them as real slashes. This breaks URLs where %2F was meaningful (e.g. an encoded path inside a path parameter). Workaround: use double-encoding (%252F) or restructure the URL to avoid the conflict.

Quick guides

JavaScript: encodeURIComponent(value) for parameter values. encodeURI(url) for whole URLs. The reverse functions handle decoding. Modern frameworks (URL constructor, URLSearchParams) handle this automatically.

Python: urllib.parse.quote(value) for component encoding. urllib.parse.quote(url, safe=':/?#&=') for full-URL encoding (preserve more characters). urllib.parse.unquote() to decode.

Bash / curl: curl --data-urlencode "key=value" handles encoding. For pre-encoded URLs, just pass them; for raw values, let curl do the encoding.

Tips

  • Use Component mode for query parameter values. Full URL mode for whole URLs.
  • Spaces become %20 in Component mode. Some systems use + instead, and both decode to a space, but they are not interchangeable in encoded form.
  • Double-encoded URLs (%2520 instead of %20) signal a pipeline bug, where something encoded an already-encoded value. Decode twice to confirm the underlying string.
  • Non-ASCII characters (accents, emoji, CJK) encode to multi-byte percent sequences. é becomes %C3%A9 because it is two UTF-8 bytes; emoji can be four or more.
  • Hash fragments (#anchor) follow the same encoding rules as the rest of the URL, but most browsers treat them more loosely. Encoding the fragment is safer when generating links programmatically.
  • Modern browsers expose the URL constructor (new URL(string)) which handles encoding properly. For new code, prefer it over manual encoding when possible.
  • For form-encoded values (POST bodies), URLSearchParams (browser) handles the + vs %20 correctly.

Related tools in this suite

The natural pairing is the Base64 Text tool, since both convert between binary-safe representations and human-readable forms, and both come up in URL-handling code. The JWT Decoder uses URL-safe base64 internally, and understanding how URL encoding differs from base64 is useful when working with both.

Take it further

URL handling at scale becomes a conversation about routing, redirect chains, query-parameter contracts, and tracking-parameter hygiene. The systems we build absorb that into deliberate architecture: short-link infrastructure, redirect rules with version control, query-parameter validation at the API layer, so that “URLs go where they should” stops being a per-feature concern.