Percent / URL Encoding

Encode arbitrary bytes as %XX sequences for URLs

Percent-encode and decode text per RFC 3986: every character outside the unreserved set is converted to its UTF-8 bytes as uppercase %XX escapes. Safe for query strings, paths, and form values. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Which characters are left unencoded?

RFC 3986 defines the unreserved set as A-Z, a-z, 0-9 and the four marks hyphen, period, underscore, and tilde. Everything else, including spaces and reserved punctuation, is percent-encoded so the result is safe in any URL position.

Percent-encoding is how arbitrary text and bytes are made safe to carry inside a URL. This tool converts any string into RFC 3986 %XX escapes and back again, handling full Unicode through UTF-8 so the round trip is always lossless.

How it works

Encoding walks the UTF-8 bytes of your input. Any byte whose character is in the unreserved set is emitted as-is; every other byte becomes a percent sign followed by its two-digit uppercase hex value:

unreserved = A-Z a-z 0-9 - . _ ~
"a b!" -> "a%20b%21"
"é"    -> "%C3%A9"   (two UTF-8 bytes)

Decoding scans for a % followed by exactly two hex digits, collects those raw bytes, then re-interprets the byte stream as UTF-8 to rebuild the original text.

Example and notes

The string name=José & co encodes to name%3DJos%C3%A9%20%26%20co. Note that the reserved characters =, &, and the space are all escaped, which is exactly what you want when placing a value inside a single query parameter. If you only need to protect a whole URL’s structure rather than one component, fewer characters need escaping, but encoding the full component set is always safe.

RFC 3986 vs encodeURIComponent — the subtle difference

JavaScript’s built-in encodeURIComponent leaves six characters unencoded that RFC 3986 says should be escaped when used inside a component: !, ', (, ), *, and ~. For most web applications this makes no practical difference, but if you are generating a query string to POST to a strict API or constructing a canonical signature for a service like AWS, the difference can cause authentication failures. This tool follows RFC 3986 strictly.

When to encode the full component versus just the path

The RFC distinguishes between encoding a component (one query-string value, a path segment) and encoding a whole URL. When you encode a full existing URL, you should not encode :, /, ?, #, &, and = because they are the structural delimiters. When you encode a single value to embed inside a URL — such as a search term or a redirect destination — you should encode those delimiters too, because they must not be misread as structure. This tool encodes everything outside the unreserved set, which is the safe choice for embedding a value.

Unicode and emoji encoding

A single emoji like 😀 takes four UTF-8 bytes (0xF0, 0x9F, 0x98, 0x80), producing four percent-escapes: %F0%9F%98%80. CJK characters typically occupy three bytes. This is important when building query strings for search engines, API endpoints, or analytics systems that have byte-length limits on URLs — the visible character count and the encoded byte count can differ dramatically.

Quick reference for commonly encoded characters

CharacterEncodedNotes
space%20use + only in form-encoded bodies
&%26must escape when embedding in query string
=%3Dmust escape in query-string values
+%2Bencode to avoid ambiguity with form-encoding space
#%23literal hash inside a value, not a fragment
/%2Fpath segment boundary character