URL Encoder/Decoder

A space in a URL breaks things. So does an ampersand where it should not be, or a foreign character an old server was never built to handle. URL encoding is the fix, a way of writing any character as a safe, standardized code so a link survives being copied, pasted, emailed, and passed between systems that speak different character sets. This tool encodes and decodes both directions, and breaks a query string down into its individual parameters so you can see exactly what a link is sending.

What this tool does

Paste any text or URL and it converts special characters into percent-encoded format, or takes an already-encoded string and turns it back into readable text. Two encoding methods are available: encodeURIComponent, meant for individual values like a query parameter or a form field, and encodeURI, meant for a complete URL where you want to keep characters like :, /, and ? untouched. If your input contains a query string, the tool automatically breaks it into a table of keys and decoded values, so you can read what a long, encoded link is carrying without decoding it by hand piece by piece.

How to use it, step by step

1. Choose Encode or Decode depending on what you are starting from.
2. Pick a method. Use encodeURIComponent for a single value, a username, a search term, an email address. Use encodeURI when you are working with a full URL and want to leave the structural characters alone.
3. Paste your text or URL into the input box.
4. Read the result below. If the input contains a query string, a breakdown table appears automatically underneath with every parameter listed as key and decoded value.
5. Copy the result with the Copy button, or click "Use as new input, swap mode" to feed the output straight back in and reverse the operation.

Who this is for

Web developers building API requests or handling query parameters use this constantly, checking that a value is encoded correctly before it goes into a request, or decoding a parameter pulled from a webhook payload to see what it contains. Anyone debugging a broken link with strange percent signs in the address bar can paste it in and read the query breakdown to find the exact parameter causing trouble. SEO practitioners checking tracking URLs or UTM parameters use the breakdown table to confirm a campaign link is structured the way it is supposed to be before it goes out in a newsletter or an ad.

What URL encoding is

A URL can only safely contain a limited set of characters: letters, digits, and a handful of symbols like -, _,., and ~. Everything else, spaces, ampersands, question marks inside a value, accented letters, emoji, gets replaced with a percent sign followed by two hexadecimal digits representing that character's byte value. A space becomes %20. An ampersand becomes %26. This is percent-encoding, and it is what makes a URL portable across browsers, servers, and programming languages that might otherwise disagree about how to handle an unusual character.

This matters because a URL's own structure depends on certain characters keeping their special meaning. A question mark introduces the query string. An ampersand separates one parameter from the next. An equals sign separates a key from its value. If a value you are inserting into a URL happens to contain one of those characters as literal text, say a search term that includes an ampersand, the URL parser reads it as structure instead of data, and the link breaks or behaves in a way you did not intend. Encoding that value first keeps the literal ampersand as data rather than letting it get mistaken for a separator.

encodeURI versus encodeURIComponent

JavaScript gives you two built-in functions for this, and mixing them up is one of the most common encoding mistakes developers make. encodeURI is built for encoding a complete URL. It leaves characters like :, /, ?, &, and = alone because those are exactly the characters a URL needs to keep its structure intact.

encodeURIComponent is built for encoding one piece of a URL, a single query parameter value, a path segment, a form field, and it encodes far more aggressively. It converts &, =, ?, and /as well, because if that individual value contained one of those characters unencoded, it would get misread as part of the URL's structure rather than as data inside it.

Run a full URL through encodeURIComponent by mistake and you get a mangled link, every slash and colon converted, turning https://example.com into an unreadable string of percent signs. Run a single search term through encodeURI and any ampersand or equals sign inside that term stays literal, which can silently corrupt the query string it gets inserted into. Picking the right one for the job matters more than most encoding guides make it sound.

Reading a query string breakdown

Everything after the ? in a URL is the query string, a list of key-value pairs separated by &, each pair joined internally by =. A link like ?q=hello+world&category=news carries two parameters, qwith the value "hello world" and categorywith the value "news". Plus signs inside a query string are a special case, a legacy convention from HTML form submissions where a space gets written as + instead of %20, and both conventions show up in the wild depending on where the URL was generated.

This is useful for debugging. A long tracking URL from an ad platform or an email campaign can carry a dozen parameters crammed into an unreadable string. Breaking it into a table instantly shows which parameters are present, what their decoded values are, and whether something like a UTM source or a redirect target matches what it is supposed to be, without manually counting ampersands and equals signs in a wall of percent-encoded text.

How this differs from Base64 encoding

Percent-encoding and Base64 encoding solve different problems and are easy to confuse since both show up constantly around URLs and web data. Percent-encoding replaces individual unsafe characters within otherwise readable text, a space, an ampersand, an accented letter, while leaving the rest of the string alone. Base64 re-encodes an entire block of data, readable or binary, into a completely different alphabet of letters, digits, and a couple of symbols, useful for embedding binary data like an image inside text-based formats such as JSON or an email. A JWT token or an embedded image often passes through Base64 encoding first, and the result may then need percent-encoding on top of that if it ends up inside a URL.

A worked example

Take the search term "coffee & tea shops." Typed directly into a URL as a query value, the ampersand would get misread as the separator between two different parameters instead of part of the search text, and the space would break the URL outright in most contexts. Running it through encodeURIComponent produces coffee%20%26%20tea%20shops., safe to insert into a query string as a single value: ?q=coffee%20%26%20tea%20shops.

Paste that full URL back into the tool with Decode selected and encodeURIComponent as the method, and the query breakdown table shows a single parameter, q, with the decoded value "coffee & tea shops." restored exactly. That round trip, readable text in, safe encoded text out, decoded text back, is the entire point of the tool in one example.

Why browsers already do some of this for you

Type a URL with a space into most modern browser address bars and the browser encodes it automatically before sending the request, which is why encoding mistakes often go unnoticed until code, not a human, is building the URL. A browser is forgiving about how a person types an address. An API client, a server-side script, or a webhook parser is not, and expects a properly encoded string from the start. That gap between what a browser tolerates and what a parser strictly expects is where most real encoding bugs live, and it is exactly the gap this tool is meant to close before code ships.

Where encoding mistakes commonly show up

Broken links after copying a URL from a document or a chat app are a frequent symptom, spaces or special characters that were fine in plain text turn a working link into a dead one once pasted somewhere that expects proper encoding. API integrations fail quietly when a parameter with an unencoded special character gets sent to an endpoint expecting clean, encoded values, and the resulting error message rarely points directly at encoding as the cause. Search functionality that passes user input straight into a URL without encoding it first can break entirely the moment someone searches for a term containing an ampersand or a percent sign of its own.

If you are building a form that constructs URLs from user input, or an API client that assembles query parameters manually instead of relying on a library to do it, encoding every value with encodeURIComponent before it goes into the URL avoids nearly all of these problems before they start. If you are working with binary or hex data alongside URLs, the binary to decimal converter covers the related base-conversion math percent-encoding is built on, converting hexadecimal byte values the same way a percent-encoded character does. If you generate test URLs with fake query parameters, pairing this tool with the fake name generator gives you realistic names to encode into search or profile parameters while testing a form.

A quick note on encoding twice by accident

Encoding an already-encoded string produces a double-encoded mess,%2520 instead of %20, because the percent sign itself gets encoded on the second pass. This happens most often when a URL passes through two layers of code that each try to encode it independently, a frontend script and a backend redirect, for instance. If a decoded result in this tool still contains percent signs followed by digits, run it through Decode a second time to check whether it was encoded twice before you go looking for a bug elsewhere in the pipeline.

Frequently asked questions