UnicodeCharactercom
TOOL · URLS

URL encoder

Percent-encode plain text for URLs, or decode an encoded URL back to plain text. Edits in either field update the other.

How it works

The tool uses three encoding strategies depending on the mode:

  • Default (checkbox off) — the platform's encodeURIComponent function. It encodes any character that isn't an unreserved ASCII character (A–Z a–z 0–9 - _ . ! ~ * ' ( )). Importantly it does encode the RFC 3986 reserved characters like /, ?, #, =, and &, so it's safe for encoding a single query-string value or a path segment.
  • Strict (checkbox on) — a custom encoder that additionally encodes the few ASCII characters encodeURIComponent leaves alone for historical reasons: ! * ' ( ). This produces output identical to Python's urllib.parse.quote(s, safe='') and is required by some signature schemes (AWS Signature V4, OAuth 1.0) that demand strict RFC 3986 compliance.

Encoding always operates on UTF-8 bytes, not on codepoints. A character like é (U+00E9) becomes %C3%A9, not %E9, because the underlying byte sequence is the UTF-8 encoding C3 A9. This is the convention browsers, servers, and modern HTTP libraries all follow. The byte-count display under each field reflects this — the encoded output is always longer than the plain text when non-ASCII is present.

Decoding reverses the process. The tool runs decodeURIComponent, which accepts any percent-encoded sequence that decodes to valid UTF-8. Invalid sequences (e.g. %C3 without a continuation byte, or %ZZ) raise an error; the tool catches that and reports the input as undecodable rather than silently dropping characters.

Encode vs encodeURI vs encodeURIComponent

JavaScript has three URL-related encoders, which is a frequent source of confusion. encodeURI is intended for whole URLs and leaves all reserved characters alone — https://example.com/path?q=1 survives unchanged because :, /, ?, and = are structural. encodeURIComponent assumes you're encoding a single component (one query value, one path segment) and encodes those structural characters so they don't break the URL. The strict mode here goes one step further and treats every non-unreserved character as needing encoding. Use whichever matches your context. For 90% of web work, encodeURIComponent is the right answer.

Worked example

Take the input search?id=café & tea:

  • Default mode: search%3Fid%3Dcaf%C3%A9%20%26%20tea. Notice that ?, =, the space, the é (as two UTF-8 bytes), and & all got encoded.
  • Strict mode: identical here, because the input contains no characters in the !*'() set.

If you intended ? and = to remain as URL syntax — meaning the input was actually a URL fragment, not a parameter value — you wanted encodeURI, not encodeURIComponent. That distinction is up to you, not the encoder.

Edge cases

Spaces have two valid encodings depending on context. Inside a query string, + is the historical shorthand for space (from application/x-www-form-urlencoded). Inside a path or fragment, only %20 is correct. This tool always emits %20; if you need +-encoded form data, do a global replace afterwards (and remember that decoding requires the inverse step). Newlines are encoded as %0A for LF and %0D%0A for CRLF if the input contains both. Surrogate pairs are handled correctly because the tool operates on the UTF-8 byte sequence, not on UTF-16 code units.

Related