URL Encoder and Decoder

What URL encoding solves

URLs can only safely contain a limited set of ASCII characters — letters, digits, and a handful of punctuation marks like - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Anything outside that set, including spaces, accented letters, emoji, or characters like & and = when they appear inside a value rather than as URL syntax, has to be converted into a safe representation before it can travel inside a URL.

Percent-encoding (also called URL encoding) is that conversion: each unsafe byte is replaced with a % followed by its two-digit hexadecimal value. A space becomes %20, an ampersand becomes %26, and the euro sign € — which is multiple bytes in UTF-8 — becomes %E2%82%AC, three percent-encoded bytes for one character.

This tool applies and reverses that conversion entirely in your browser, using the same rules browsers and servers use, so you can see exactly what a given string becomes once it's dropped into a URL, a query string, or a redirect parameter.

encodeURI vs encodeURIComponent, in practice

JavaScript exposes two encoding functions with genuinely different behavior, and picking the wrong one is one of the most common URL bugs [3](https://encodings.dev/url-encode-vs-encodeuricomponent/). encodeURI() is meant for encoding a whole URL that already has its structural characters in place — it leaves : / ? # [ ] @ ! $ & ' ( ) * + , ; = untouched because those characters are meaningful URL syntax, and only encodes things like spaces and non-ASCII characters.

encodeURIComponent() is meant for encoding a single piece — a query parameter's value, a path segment — that will be inserted into a URL. It encodes far more aggressively, including & = ? / and #, because those characters would otherwise be misread as URL structure rather than part of your data [4](https://stackoverflow.com/questions/4540753/should-i-use-encodeuri-or-encodeuricomponent-for-encoding-urls).

Concretely: encodeURI("https://example.com/search?q=cats&dogs") returns the string almost unchanged, because & and = and : are all left alone as valid URL syntax — only truly unsafe characters would be touched. But encodeURIComponent("cats&dogs") returns "cats%26dogs", because as a standalone value, the & needs to be escaped or it would be misread as separating two query parameters instead of being part of one value.

The practical rule: use encodeURIComponent for anything you're inserting into a query string, path segment, or fragment as data — search terms, usernames, file names. Use encodeURI only when you have a complete, already-structured URL and just need to escape stray unsafe characters in it.

decodeURI vs decodeURIComponent

These mirror their encoding counterparts. decodeURIComponent() decodes every percent-encoded sequence it finds, including %26 back to & and %3D back to =. decodeURI() deliberately refuses to decode sequences that represent reserved URL characters, leaving them percent-encoded so a full URL doesn't get corrupted into something structurally different.

In practice, when you're pulling a single value back out of a query string — reading req.query.q on a server, or new URLSearchParams(location.search).get("q") in a browser — decodeURIComponent is almost always the right tool, and most frameworks already call it for you automatically when parsing query strings.

Worked example: encoding a search query

Take the search phrase "C++ & JavaScript". Encoding it with encodeURIComponent gives "C%2B%2B%20%26%20JavaScript" — the plus signs become %2B, the space becomes %20, and the ampersand becomes %26. Drop that into a URL as ?q=C%2B%2B%20%26%20JavaScript and the server reads the value back exactly as "C++ & JavaScript".

Compare that to naively using a raw + for spaces, which is a separate legacy convention from the application/x-www-form-urlencoded format used in classic HTML form submissions and query strings — not the same as %20. Both %20 and + can mean "space" depending on context, which is exactly the kind of ambiguity that trips people up when mixing tools; percent-encoding with %20 is unambiguous and always safe to use.

Now take an email address as a value: "name+test@example.com". Encoded, the + becomes %2B and the @ becomes %40, giving "name%2Btest%40example.com" — important because an un-encoded + in a query string value can be silently interpreted as a space by systems following the form-encoding convention, corrupting the address.

Building and reading query strings

A query string is everything after the ? in a URL, made of key=value pairs joined by &, like ?category=shoes&sort=price&page=2. Each key and each value should be independently percent-encoded with encodeURIComponent before being joined — encode the pieces first, then assemble the string, never the other way around, or you'll double-encode or under-encode structural characters.

Reserved characters — : / ? # [ ] @ as "gen-delims" and ! $ & ' ( ) * + , ; = as "sub-delims" — get special treatment because they have structural meaning somewhere in a URL. Unreserved characters — letters, digits, and - . _ ~ — never need encoding at all, in any context.

Modern JavaScript has a built-in URLSearchParams API that handles all of this encoding automatically: new URLSearchParams({ q: "cats & dogs", page: "2" }).toString() produces "q=cats+%26+dogs&page=2" (note it uses + for spaces, following the form-encoding convention rather than %20, which is a subtlety worth knowing when comparing its output to encodeURIComponent's).

UTM parameters and marketing links

UTM parameters — utm_source, utm_medium, utm_campaign, utm_term, utm_content — are query string values used to track where traffic comes from, and they need the same encoding discipline as any other query value. A campaign name with a space or special character, like "Spring Sale!", must become utm_campaign=Spring%20Sale%21 or the URL will be malformed or truncated at the unencoded character by some parsers.

A common real-world mistake is building UTM links by hand and forgetting that & inside a campaign name ("Buy 1 & Get 1") will be read as starting a new parameter instead of being part of the value, silently breaking the tracking data downstream in analytics tools. Running the value through a URL encoder first — turning it into "Buy%201%20%26%20Get%201" — avoids that entirely.

Spaces are especially easy to get wrong in UTM links pasted into spreadsheets or ad platforms; some tools auto-encode them as %20, others leave literal spaces that later get silently converted to + by a form submission, and either can cause mismatched or double-encoded links if you're not consistent about when encoding happens.

Common mistakes people make

Double-encoding is probably the most frequent error: encoding a string that's already encoded turns %20 into %2520, because the % itself gets encoded to %25 on the second pass. If a decoded value still contains %XX sequences after you decode it once, it was likely encoded twice somewhere in the pipeline.

Using encodeURI on a value instead of encodeURIComponent is the second most common — since encodeURI leaves & = ? alone, a value containing those characters ends up structurally corrupting the URL instead of being safely escaped.

Forgetting non-ASCII characters need multi-byte encoding: a name like "María" isn't just one accented character escaped — in UTF-8 the í becomes two bytes, so the encoded form is "Mar%C3%ADa", not a single two-digit sequence.

Manually string-replacing only spaces and assuming the rest is fine misses reserved characters like &, =, #, and + that also need encoding whenever they appear as literal data rather than URL structure.

Reading percent-encoded strings

Each %XX triplet represents one byte in hexadecimal. %20 is decimal 32, the space character. %2F is decimal 47, the forward slash. %E2%82%AC is three bytes — E2, 82, AC in hex — which together form the UTF-8 byte sequence for the € symbol; you can't decode multi-byte UTF-8 characters one %XX pair at a time and get a meaningful result, which is why decoding tools always process the full byte sequence together.

A fragment identifier (the part after #) is a special case: it's never sent to the server at all, so encoding rules there mostly matter for how the browser and JavaScript interpret it client-side, not for server-side processing.

Privacy and limits

Encoding and decoding both happen locally in your browser using standard JavaScript encode/decode functions — no query string, token, or URL you paste here is sent to a server or logged, which matters since query strings often carry session identifiers or personal data.

There's no artificial length restriction imposed by this tool, though real-world URLs are practically capped by browsers and servers — most browsers support URLs well past 2,000 characters, but many servers and proxies impose their own lower limits, so extremely long encoded query strings can fail elsewhere even if they encode and decode correctly here.