URL Encode / Decode

About URL Encode / Decode

URL encoding (percent-encoding) escapes characters that aren't safe in a URL — spaces become %20, and ampersands, slashes, and non-ASCII text get their own %XX codes — so links and query strings work reliably. Paste text to encode it, or an encoded string to decode it back to plain text. Both directions run in your browser with no upload.

Why URLs need escaping at all

A URL is not free text — it is a structured string where certain characters carry meaning. A question mark starts the query, an ampersand separates parameters, a slash separates path segments, and a hash begins the fragment. If a value you are putting into a URL contains one of those characters, the parser on the other end has no way to tell your data from the structure.

Percent-encoding solves this by replacing a character with a percent sign and its byte value in hexadecimal. A space becomes %20, an ampersand %26, a question mark %3F. The receiving side decodes after it has finished splitting the URL into its parts, so the structure is parsed first and the data survives intact.

Encode the parts, never the whole URL

The commonest mistake is running an entire URL through an encoder. That escapes the slashes and the colon in https:// along with everything else, producing a string that is no longer a URL at all. Encoding applies to individual components — one query-parameter value, one path segment — not to the assembled address.

This is why languages give you two functions. JavaScript's encodeURI leaves URL structure alone and is for tidying a whole address; encodeURIComponent escapes the reserved characters too and is what you want for a value going into a parameter. If you are inserting user input into a query string, it is almost always the component version.

Plus signs, spaces, and the form-encoding exception

A space is %20 in a proper URL, but HTML form submissions use a different, older encoding where a space becomes a plus sign. Both appear in the wild, and the two are not interchangeable: decoding a query string with the wrong rule turns a genuine plus in an email address or phone number into a space, silently corrupting the value.

The practical consequence is that a literal plus must always be encoded as %2B when it appears in a query string. This is the reason address forms sometimes lose the plus in an email alias, and the reason phone numbers arrive missing their country-code prefix.

Non-ASCII text and double encoding

Characters outside ASCII are first converted to UTF-8 bytes, then each byte is percent-encoded, so one accented character usually becomes two escape sequences and an emoji becomes four. That is why an encoded non-English string looks so much longer than the original — the length is bytes, not letters.

Double encoding is the failure to watch for. Encoding an already-encoded string turns the percent sign itself into %25, so %20 becomes %2520. The symptom is a URL full of %25 and a page showing literal escape codes as text. It happens when a value passes through two layers that each try to be helpful — decode once and check before encoding again.

Frequently asked questions

What does %20 mean in a URL?

%20 is the percent-encoded form of a space: % marks an encoded byte and 20 is the hex value of a space. In form data (application/x-www-form-urlencoded) a space is often encoded as + instead.

Should I encode the whole URL or just a value?

Encode individual query values, not the entire URL. Percent-encoding a full URL escapes its structural :, /, and ? characters and breaks the link. Encode each parameter, then assemble the URL.

Which characters need URL encoding?

Reserved and unsafe characters — spaces, and : / ? # [ ] @ ! $ & ' ( ) * + , ; = plus % itself — are escaped. Letters, digits, and - _ . ~ are left as-is.

What's the difference from Base64?

URL encoding escapes only unsafe characters with %XX sequences and stays human-readable; Base64 re-encodes all data into a different alphabet. Use URL encoding for links, Base64 for embedding binary data in text.

Is my input private?

Yes — encoding and decoding happen locally in your browser and nothing is uploaded.