URL Encoder / Decoder

What is URL encoding?

URL encoding — formally percent-encoding — rewrites characters a URL cannot contain safely as a percent sign followed by two hexadecimal digits. A space becomes %20. An ampersand inside a value becomes %26. The rule is mechanical: take the byte, write it in hex, put a % in front.

The reason it exists at all is that a URL is not free-form text — certain characters carry structural meaning. A / separates path segments, a ? starts the query string, a & separates parameters, a # starts a fragment. If the actual data you're placing in a URL contains one of those characters, it has to be escaped so it reads as data rather than as another piece of URL structure.

What is a URL encoder?

A URL encoder is a tool that applies percent-encoding for you, so you don't have to hand-convert characters to hex. The useful ones — including this one — do more than that single conversion: they distinguish between encoding a whole URL and encoding one value inside it, because those are genuinely different operations with different correct answers, not two names for the same thing.

The workspace above runs entirely as JavaScript in your browser, calling the same encodeURI, encodeURIComponent and URLSearchParams functions your own code would call, so what you see here is exactly what you'd get in production — not an approximation.

What is URL decoding?

Decoding reverses the process: it scans for %XX sequences, converts each back to its original byte, and reassembles the UTF-8 byte stream back into text. Anything that isn't a percent-encoded sequence passes through unchanged.

Decoding can fail in a way encoding never does: the input can be malformed. A lone %, a truncated %2, or a non-hex sequence like %ZZ is not valid percent-encoding, and there is no sensible guess to make on your behalf. The tool reports this plainly rather than silently dropping or mangling the bad sequence.

What is percent encoding?

Percent encoding is the general mechanism: any byte can be represented as % plus its two-digit hexadecimal value. For a non-ASCII character, the character is first converted to UTF-8 — which may be two, three or four bytes — and every one of those bytes is percent-encoded in sequence. That's why a single emoji can expand into a string like %F0%9F%94%97: four bytes, four %XX groups.

Not every character needs encoding. Letters, digits, and a defined set of "unreserved" punctuation (- _ . ! ~ * ' ( )) are left as-is by both native functions, because they carry no special meaning and are always safe. Encoding them anyway wouldn't be wrong exactly, just noisy — and it isn't what the standard functions do, so this tool doesn't do it either.

URL encoding vs URI encoding

In casual usage, "URL encoding" and "URI encoding" mean the same mechanism — percent encoding. The distinction that actually matters in practice is the one this tool leads with: encoding an entire address versus encoding one piece of data that will live inside it. Get that choice wrong and the mechanism being correct doesn't save you.

encodeURI() vs encodeURIComponent()

This is the single most important distinction in this whole tool, and the most common source of broken links in real code.

encodeURI() assumes you're handing it an entire, structurally complete URI. It escapes characters that are unsafe anywhere — spaces, quotes, angle brackets — but leaves alone the characters a URI needs to keep its shape: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Run it on https://example.com/a b?c=d and you get https://example.com/a%20b?c=d — still a working URL, just with the space fixed.

encodeURIComponent() assumes you're handing it one value with no structural role of its own. It escapes all of those same reserved characters, because inside a single component they aren't structure — they're just data that happens to look like structure. Run it on the same string and you get https%3A%2F%2Fexample.com%2Fa%20b%3Fc%3Dd, which is correct behaviour for the function, but almost certainly not what you wanted if that string was meant to remain a working link.

The practical rule: if what you have is a complete address you want to keep dereferenceable, use encodeURI. If what you have is one piece of data destined for a single slot — a query value, a path segment — use encodeURIComponent. The second case is far more common in everyday code.

When to use encodeURI()

Reach for encodeURI() when you have a full URL, typed or generated with spaces or other unsafe characters in it, and you want to fix just those while leaving the URL's own punctuation alone. It's a reasonable choice for cleaning up a URL a user pasted in with stray spaces, or for encoding a complete redirect target. It is a poor choice for encoding a query parameter value, because it will leave characters like & and = inside that value unescaped — which then get misread as extra parameter boundaries.

When to use encodeURIComponent()

This is the one to reach for by default. Any time you're building a URL programmatically — appending a search term, a redirect path, a filename — and inserting it into a query string, a path segment, or after a fragment, encode that piece on its own with encodeURIComponent() before concatenating it into the larger URL. Never run it on the whole URL at once; that's the mistake this tool exists partly to prevent.

Query parameters

A query parameter is a name=value pair after the ? in a URL, with pairs separated by &. Both the name and the value are components in the sense above — either one can contain characters that need escaping, and each is encoded independently before being joined with =. Query Parameter mode above does exactly this: it encodes the name and the value separately with encodeURIComponent(), then joins them.

Query string encoding

A full query string is several of those pairs joined with &. You could build one by hand with encodeURIComponent() and template strings, but URLSearchParams does the same job with less room for error — it automatically handles the leading ?, the & separators, and correct per-value encoding, and it copes cleanly with duplicate keys, which hand-built string concatenation tends to get wrong.

URLSearchParams

URLSearchParams is a browser API purpose-built for query strings — both constructing and reading them.

const params = new URLSearchParams();
params.set("search", "hello world");
params.toString();        // "search=hello+world"

const parsed = new URLSearchParams("?tag=js&tag=regex");
parsed.getAll("tag");     // ["js", "regex"]

Notice the output: hello+world, not hello%20world. This is not a bug or an inconsistency — URLSearchParams deliberately follows the application/x-www-form-urlencoded convention, the same one HTML forms have used since the 1990s, where a space is a +. Don't assume its output is interchangeable, character for character, with encodeURIComponent()'s output — both are correct for what they're each designed to do, they're just different conventions.

How spaces are encoded

There are two correct encodings for a space, and which one applies depends entirely on context. Standard percent-encoding — what encodeURI() and encodeURIComponent() produce — always uses %20. The application/x-www-form-urlencoded convention — what HTML forms submit and what URLSearchParams produces — uses +. Both are valid; they just belong to different specifications, and mixing them up is a common source of subtly broken URLs.

What does %20 mean?

A space is ASCII byte 32. In hexadecimal that's 20. Percent-encoding writes any byte as % followed by its two-digit hex value, so byte 32 becomes %20. It's the encoding you'll see most often simply because spaces are the most common character URLs need to escape.

What does %2F mean?

%2F is the percent-encoded forward slash. You'll meet it when a literal slash needs to be treated as data rather than as a path separator — for instance, a filename containing a slash that's being passed as a single path segment or query value. Some servers reject %2F in a path for security reasons even though it's technically valid encoding, which is worth knowing if you hit an unexpected 400 error.

What does %26 mean?

%26 is the percent-encoded ampersand. It's required whenever a literal & needs to appear inside a query value — without encoding it, the & would be read as the start of the next parameter, silently truncating your value and corrupting the query string.

Plus sign vs space

This deserves its own heading because it trips people up constantly. In standard percent-encoding, + is just a literal plus sign — it does not mean space, and a genuine + character must itself be encoded as %2B if it needs to survive as data. It's only inside application/x-www-form-urlencoded content — form submissions and URLSearchParams — that + is interpreted as a space on decode.

The failure mode this causes in real projects: someone calls encodeURIComponent() on a value containing a literal + (a phone number, a base64 fragment, a chemical formula like C++), gets %2B correctly, and then a downstream system decodes it with form-decoding rules that turn any bare + into a space — except here there wasn't a bare +, so nothing breaks. The break happens in the opposite direction: form-encoded data containing a real + character gets misread as a space by something expecting strict percent-decoding. Know which convention the far end of your request actually expects.

Unicode URL encoding

Non-ASCII text — Hindi, Arabic, Chinese, emoji — is encoded the same way as everything else: convert to UTF-8 bytes first, then percent-encode each byte. A Devanagari character typically becomes three %XX groups; a common emoji becomes four. This is exactly what your browser does with encodeURIComponent(), and it's what this tool reproduces, since it calls that same function rather than any custom logic.

Common URL encoding mistakes

• Running encodeURIComponent() on a whole URL. It escapes the URL's own :, / and ?, turning a working link into an inert string of percent codes.
• Running encodeURI() on a single value. It leaves & and = unescaped inside that value, which then get misread as extra query structure.
• Treating + and %20 as interchangeable everywhere. They belong to different conventions and only one is correct for a given context.
• Encoding an already-encoded string. This produces double encoding — a literal % in %20 becomes %25, giving %2520, which decodes back to %20 rather than a space.
• Using HTML entities as URL encoding. & is not the same thing as %26, and putting one where the other belongs breaks the value.
• Assuming every character needs escaping. Letters, digits and unreserved punctuation are left alone by design; encoding everything just makes the result harder to read for no benefit.
• Building query strings with manual string concatenation. It's easy to forget to encode a value, mishandle an empty value, or mangle duplicate keys. URLSearchParams handles all three correctly.

URL encoding in JavaScript

encodeURI("https://example.com/a b?c=d");
// "https://example.com/a%20b?c=d"

decodeURI("https://example.com/a%20b?c=d");
// "https://example.com/a b?c=d"

encodeURIComponent("hello world & tools");
// "hello%20world%20%26%20tools"

decodeURIComponent("hello%20world%20%26%20tools");
// "hello world & tools"

const params = new URLSearchParams();
params.set("search", "hello world");
params.set("tag", "js");
params.append("tag", "regex");
params.toString();
// "search=hello+world&tag=js&tag=regex"

Note that URLSearchParams.append() adds a new pair, while .set() replaces any existing value for that name — a distinction that matters the moment you need duplicate keys, like a multi-select filter.

URL encoding in APIs

REST APIs commonly take input as path segments or query parameters, and both need component-style encoding for any value that isn't already URL-safe. A user ID that happens to be a UUID needs nothing; a free-text search term almost always does. When calling fetch(), build the query string with URLSearchParams rather than hand-concatenating — it's shorter and it's correct by construction.

const params = new URLSearchParams({ q: "hello world", page: "2" });
fetch(`/api/search?${params}`);

URL encoding in HTML forms

A standard HTML form with method="get" serializes its fields using application/x-www-form-urlencoded — the same convention URLSearchParams implements, spaces and all. A form with method="post" and the default encoding also uses this format in the request body, unless you explicitly set enctype="multipart/form-data" for file uploads. This is why form-submitted data and manually component-encoded data can look slightly different for the same input — they're following the same underlying idea through two different code paths with one small convention difference.

URL encoding vs HTML encoding

These solve different problems and are not interchangeable. URL encoding (%26) makes text safe to place inside a URL. HTML encoding (&) makes text safe to place inside HTML markup, so a browser displays it as a character rather than interpreting it as the start of a tag or entity. Text that will end up inside an href attribute that is itself HTML sometimes legitimately needs both, applied in the correct order — URL-encode the value first, then HTML-encode the resulting attribute string — but neither substitutes for the other.

URL encoding vs Base64

Base64 re-encodes arbitrary bytes into a compact alphabet of 64 printable characters, commonly used to embed binary data — an image, a key — as text. Standard Base64 output can itself contain characters unsafe in a URL (+, /, =), which is why a "URL-safe Base64" variant exists separately. Percent-encoding, in contrast, targets exactly the characters a URL cannot contain unencoded, working directly on already- textual data. They are different tools for different jobs, not two options for the same one — if you have binary data, you likely want Base64 first, then percent-encoding if that Base64 output needs to sit inside a URL component.

Common URL encoding examples

Input	encodeURIComponent()
hello world	hello%20world
a & b	a%20%26%20b
100%	100%25
C++	C%2B%2B
what?	what%3F
a/b	a%2Fb
user@example.com	user%40example.com

URL vs URI vs URN

URI (Uniform Resource Identifier) is the umbrella term for any string that identifies a resource. URL (Uniform Resource Locator) is a URI that also tells you how to get the resource — the familiar https://example.com/page kind. URN (Uniform Resource Name) identifies a resource by name within a namespace without saying where to find it, such as urn:isbn:9780141036144 for a book. In everyday development, "URL" and "URI" are used almost interchangeably, and this tool follows that convention — the JavaScript methods themselves are named encodeURI, matching the broader, more accurate term, even though most people reach for it to encode what they'd casually call a URL.

Frequently asked questions