URL Encoder / Decoder

This free URL encoder and decoder converts text to a percent-encoded, URL-safe form and back again in real time, entirely in your browser. Type or paste on the left, switch between encode and decode, and read the result on the right. It offers both component encoding, which is what you want for individual query parameters, and full-URL encoding, which leaves structural characters intact. Below the tool is a thorough guide to what URL encoding is, why it exists, exactly which characters get encoded and why, and the mistakes that cause broken links and lost data.

What is URL encoding?

URL encoding, also called percent-encoding, is a method for representing characters in a web address that would otherwise be unsafe, ambiguous, or simply not allowed. A URL can only reliably contain a limited set of characters from the ASCII range. Anything outside that set, including spaces, many punctuation marks, and every non-English character, must be converted into a form built only from permitted characters. URL encoding does this by replacing each problematic character with a percent sign followed by two hexadecimal digits that represent the character’s byte value.

The most familiar example is the space. A literal space is not allowed inside a URL, so it is encoded as %20. The % introduces an escape sequence and 20 is the hexadecimal value of the space character in the ASCII table. You have seen %20 in countless web addresses; now you know exactly what it means. The tool above performs this substitution for every character that needs it and reverses it on decode.

Why URL encoding exists

The rules for what a URL may contain were set out in the standards that define web addresses, and they exist for a practical reason: different characters have different jobs inside a URL, and the structure must remain unambiguous. Consider an address with a query string like search?q=cats&page=2. Here the ? marks the start of the query, the & separates parameters, and the = ties each key to its value. These characters are structural punctuation. If a user searched for the literal text cats & dogs, putting that raw text into the URL would be a disaster, because the & in the search term would look exactly like the separator between parameters, and the server would misread where one value ends and the next begins.

URL encoding resolves this by giving every character a single, unambiguous role. Structural characters keep their special meaning when they appear raw, while the same characters inside a value are encoded so they cannot be mistaken for structure. The ampersand in cats & dogs becomes %26, and the space becomes %20, producing cats%20%26%20dogs, which the server reads as one intact value. This is the entire reason the encoding exists.

How percent-encoding works

The mechanism is straightforward. Each character that must be encoded is first looked up as a byte value, then written as a percent sign followed by that value in two hexadecimal digits. The exclamation mark, byte value 33, becomes %21. The forward slash, byte value 47, becomes %2F. The encoding is case-insensitive in the hex digits, though uppercase is conventional and what this tool produces.

For characters beyond the basic ASCII range, the process first converts the character to its UTF-8 byte sequence and then percent-encodes each byte individually. A character like é, which is a single character to a human, is two bytes in UTF-8, so it encodes to two percent sequences, %C3%A9. An emoji, which can be four bytes, becomes four percent sequences. This is why an encoded non-English URL can look surprisingly long, and why correct UTF-8 handling matters so much. The tool above handles this automatically using the browser’s native, standards-compliant encoding functions.

Which characters get encoded?

Not every character needs encoding. The standards define a set of “unreserved” characters that are always safe and never need to be touched. These are the uppercase and lowercase letters, the digits 0 through 9, and four punctuation marks: the hyphen, the period, the underscore, and the tilde. Everything else either has a reserved structural meaning or is unsafe, and the right treatment depends on whether you are encoding a whole URL or just one piece of it.

Component encoding vs full-URL encoding

This is the single most important distinction to understand, and it is the choice the checkbox in the tool controls. The two modes correspond to the two main JavaScript functions, encodeURIComponent and encodeURI, and using the wrong one is the most common URL-encoding mistake.

Component encoding is for a single piece of data that will be slotted into a larger URL, such as one query parameter value, one path segment, or a search term. It encodes the structural characters &, /, ?, =, and # as well, because in this context those characters are data, not structure, and must not be allowed to alter the URL’s shape. This is what you want the vast majority of the time, which is why the tool defaults to it.

Full-URL encoding is for encoding an already-assembled, complete URL. It deliberately leaves the structural characters alone, because they are doing their structural job. It only encodes things like spaces and other clearly-unsafe characters. If you used full-URL encoding on a value that itself contained an ampersand, that ampersand would survive unencoded and break your parameter boundaries.

The plus sign and space confusion

One of the most persistent sources of bugs in URL handling is the relationship between the plus sign and the space. In the percent-encoding standard, a space is %20. But in an older convention specific to HTML form submissions, a space in the query string is encoded as a literal + instead. This means that depending on where a URL came from, a space might appear as either %20 or +, and a literal plus sign in data must always be encoded as %2B to avoid being misread as a space.

The practical upshot is that if you decode a query string and find that real plus signs have turned into spaces, or that what should be spaces are showing as plus signs, you are looking at the form-encoding convention rather than strict percent-encoding. Knowing both conventions exist saves a great deal of confusion, and it is why a value containing a plus sign, such as a phone number with a country code, must be carefully encoded before it goes into a URL.

How to use this URL encoder

Choose Encode or Decode with the toggle at the top. In Encode mode, type or paste your text on the left and the percent-encoded result appears on the right as you type. In Decode mode the panes reverse: paste an encoded string on the left and read the human-readable original on the right. The Swap button exchanges input and output, which is useful for round-tripping or for quickly checking that an encode and decode produce what you expect. Leave the component checkbox ticked for individual values, which is the common case, and untick it when you are encoding a complete URL whose structure should be preserved. The status bar shows character counts and clearly flags when a decode fails because the input contains a malformed percent sequence.

A worked example, character by character

Seeing the encoding applied to a realistic string makes the rules concrete. Suppose a user types the search query price < $50 & new? and you need to put it into a URL as the value of a q parameter. Walking through it with component encoding, each character is examined in turn. The letters and digits are unreserved, so they pass through unchanged. The spaces become %20. The less-than sign becomes %3C. The dollar sign becomes %24. The ampersand, which would otherwise look like a parameter separator, becomes %26. The question mark, which would otherwise look like the start of a query string, becomes %3F. The finished value is price%20%3C%20%2450%20%26%20new%3F, which slots safely into search?q=price%20%3C%20%2450%20%26%20new%3F with no risk of the search term being mistaken for URL structure.

Notice how every character that could have confused the URL parser, the ampersand and the question mark in particular, has been neutralized into a percent sequence, while the structural ? and = that belong to the URL itself remain untouched because they were never part of the value. That separation is the whole point. Paste the original string into the tool above with component mode on to see the same result.

Where URL encoding matters in practice

URL encoding is one of those invisible mechanisms that quietly makes the web work. Here are the everyday situations where getting it right matters.

Search and filter links

Any time a search term or filter value goes into a link, it must be component-encoded. A product search for a term containing a slash, an ampersand, or a space will silently break or return the wrong results if the value is dropped into the URL raw. This is the most common place developers meet the encoding.

Building API requests

When you construct an API request URL with query parameters, each parameter value should be encoded individually. A value that contains JSON, a timestamp range, or an email address with a plus sign in it will corrupt the request unless encoded. If the decoded value turns out to be JSON, the JSON formatter is the natural next stop for inspecting it.

Tracking and campaign URLs

Marketing links carry parameters like campaign names and sources that often include spaces and punctuation. Encoding them keeps the analytics clean and prevents links from breaking when shared across platforms that may otherwise mangle raw characters.

Tokens and encoded data in URLs

Sometimes structured or encoded data rides along in a URL, including tokens. A JWT uses a URL-safe Base64 variant precisely so it can sit in a URL without further encoding, and a Base64 value placed into a query string usually still needs URL encoding because standard Base64 contains + and /, both of which are problematic in URLs.

Troubleshooting broken or garbled URLs

When a link does not work or a parameter arrives mangled, the cause is almost always one of a few encoding problems. Recognizing them quickly is a practical skill.

A value cut short at an ampersand or hash

If a parameter value seems truncated, an unencoded & or # inside it is the likely culprit. The server stopped reading the value at that character because it looked like a separator or the start of a fragment. Encoding the value as a component fixes it.

The wrong encoding function was used

If structural characters that should have been escaped survived in your data, you probably used full-URL encoding where you needed component encoding. Re-encode the individual value with component mode.

A malformed percent sequence

A lone % not followed by two valid hex digits will cause a decode to fail outright, because the decoder cannot interpret the escape. This often happens when a literal percent sign in data was not itself encoded as %25. The tool above reports this case clearly rather than producing garbage.

Spaces and plus signs swapped

As covered above, mismatched conventions between %20 and + for spaces lead to spaces appearing as plus signs or vice versa. Identify which convention the source used and handle it consistently.

The double-encoding trap

A particularly confusing class of bug is double encoding, where a value is URL-encoded twice. This usually happens when a value passes through two layers of code that each helpfully encode it, or when an already-encoded value is encoded again by mistake. The tell-tale sign is a percent sign that has itself been encoded: you see %2520 where you expected %20, because the % of the original %20 was re-encoded to %25, producing %25 followed by 20.

The fix is to decode the value the same number of times it was encoded. If a single decode leaves you with a string that still contains percent sequences and looks encoded, decode it again. The Swap and Decode features of the tool above make this iterative checking quick. The deeper fix, in your own code, is to be disciplined about encoding a value exactly once, at the boundary where it enters the URL, and never again.

URL encoding compared to other encodings

It helps to place URL encoding alongside its relatives, because they are easy to confuse and each solves a different problem. URL encoding makes characters safe specifically for web addresses by escaping them as percent sequences. Base64, covered in a separate tool, makes arbitrary binary data safe as text using a 64-character alphabet, and is about transport rather than URL structure. HTML entity encoding, a third scheme, escapes characters so they display correctly in a web page rather than being parsed as markup, turning a less-than sign into < so it shows as a literal angle bracket instead of starting a tag.

The common thread is that all three are reversible format transformations with no key and no secrecy, which means none of them provide any security. They differ only in what context they make data safe for: URLs, text channels, or HTML display respectively. Choosing the right one is a matter of matching the encoding to where the data is going, and using more than one in sequence only when the data genuinely passes through more than one of those contexts.

The anatomy of a URL

To understand why different parts of a URL are encoded differently, it helps to see how a URL is structured. Take a full address such as https://codezips.com/tools/url-encoder?q=hello+world&lang=en#results. It breaks into distinct components, each with its own rules. The scheme, https, says which protocol to use. The host, codezips.com, names the server. The path, /tools/url-encoder, identifies the resource on that server. The query string, everything after the ?, carries parameters as key-value pairs joined by &. Finally the fragment, after the #, points to a location within the page and is never even sent to the server.

Each component permits a slightly different set of characters, which is why a one-size-fits-all approach to encoding does not work. A slash is meaningful structure inside the path but would be data if it appeared inside a single query value. The question mark is structure when it separates the path from the query, but data if it appears inside a search term. This is precisely why component encoding exists: it treats a value as pure data and escapes anything that might otherwise be read as one of these structural markers, so the value can be safely placed into any component without disturbing the URL’s shape.

When you decode a complete URL with the tool above in full-URL mode, the structural characters are preserved so the address stays intelligible, whereas decoding a single extracted parameter value is best done in component mode so that escaped structural characters are correctly restored to their literal meaning. Matching the mode to whether you are handling a whole URL or one piece of it is the key to getting consistent results.

Standards and a little history

Percent-encoding dates back to the earliest specifications of the web address itself and has been refined over the years into the modern standard that governs URIs today. The core idea has remained remarkably stable: reserve a small set of characters for structure, declare another small set always safe, and require everything else to be escaped as a percent sequence. What has evolved is mainly the careful handling of international characters, which the modern standard resolves by mandating UTF-8 as the encoding applied before percent-escaping. This is why this tool, like modern browsers, converts text to UTF-8 first, ensuring that a URL containing non-English text behaves identically everywhere rather than depending on guesswork about the original character set.

The practical lesson from this history is that URL encoding is deliberately conservative. It assumes very little about what systems along the way can handle, which is exactly why it has remained reliable across decades of changing browsers, servers, and networks. When you encode a value correctly, you are leaning on a standard designed to survive almost any system it passes through, which is the same conservative philosophy that has kept the web’s other text-safe encodings useful for just as long.

Frequently asked questions