URL Encoding Explained: Encode and Decode URLs the Right Way

By ZeroFee Tools · October 4, 2026 · 6 min read

You have probably clicked a link that broke the moment it contained a space, an ampersand, or a non-English character. URLs only allow a limited alphabet, so everything else must be percent-encoded: each unsafe character becomes a % sign followed by two hex digits. The free URL Encoder and Decoder on ZeroFee Tools performs that conversion in both directions, with the result appearing live as you type.

Developers use it to build safe query strings and API calls, marketers use it to encode campaign links, and everyone else uses it to decode those unreadable %20-filled addresses back into plain text. If you work with tokens, you may also want the JWT decoder or the Base64 encoder, which handle the encodings that often live inside URLs.

What is URL encoding (percent-encoding)?

URL encoding, also called percent-encoding, replaces characters that are not allowed in a URL with a % sign followed by two hexadecimal digits. A space becomes %20, an ampersand becomes %26, and a non-ASCII character becomes a sequence of encoded bytes. Encoding keeps links valid, clickable, and correctly interpreted everywhere.

The URL specification only permits letters, digits, and a small set of symbols. Everything else, from spaces to emoji to non-Latin scripts, must be escaped before it can travel inside an address. That is why a search for "hello world" becomes hello%20world in the address bar, and why a value containing & would otherwise split your query string into two separate parameters.

Encoding matters most when you build URLs programmatically: form values, search terms, redirect targets, and API parameters all need encoding before they are concatenated into a link. Paste any of these into the tool, keep the mode on Encode, and the safe version appears instantly. If you received a URL that already looks like alphabet soup, switch to Decode mode: the tool restores the original text and shows a clear error message if the input is not valid encoded text. For links carrying leftover tracking clutter after decoding, the tracking URL cleaner strips it away.

When should I use encodeURIComponent vs encodeURI?

Use encodeURIComponent when encoding a single value that will be inserted into a query string, because it also encodes reserved characters like &, =, ? and #. Use encodeURI when you already have a complete, valid URL and only want to escape unsafe characters such as spaces or unicode letters, leaving the URL structure untouched.

The tool offers both methods as radio options because they solve different problems. encodeURIComponent is the strict one: it encodes almost everything except letters, digits, and a few safe symbols, so a value like fish & chips becomes fish%20%26%20chips and cannot break your query string. That is the correct choice for form fields, search boxes, and any user input you append as ?q=...

encodeURI is the gentle one: it leaves structural characters like : / ? & = # alone and only encodes what is genuinely unsafe, such as spaces and non-ASCII letters. Use it when you already hold a full URL: https://example.com/café menu becomes valid while its slashes and colons survive. The classic mistake is running encodeURI over a raw value containing an ampersand: the & survives and silently splits your parameter in two. When in doubt, encode each value with encodeURIComponent and assemble the URL yourself.

Why does a decoded URL sometimes still look wrong?

Usually because of double-encoding, where % was itself encoded into %25, or because plus signs were used for spaces in a query string but not in the path. Decode mode converts %25 back to % first, so running decode twice resolves most cases. If the source used + for spaces, replace + with a space before decoding.

Double-encoding happens when a URL passes through two systems that each encode it: the % in %20 becomes %2520. Decoding once gives you %20, which still looks encoded, and decoding a second time gives you the space. The tool makes this painless: Decode mode shows its result live, so you can copy the output back into the input and decode again until the text reads naturally.

Another common surprise is the plus sign. In form-encoded query strings, + means space, but in a URL path it is a literal plus. If you decode a query string and still see + characters where spaces should be, swap them for spaces first. When a URL has encoding damage beyond simple percent codes, try the dedicated URL encoding fixer, and use the URL parameter checker to inspect each query parameter individually after decoding.

How to encode or decode a URL in 4 steps

1. Choose Encode or Decode. Select Encode to convert text into percent-encoded form, or Decode to restore an encoded URL to readable text.
2. Pick the encoding method. Use encodeURIComponent for single query-string values, or encodeURI when you want a complete URL to keep its : / ? & = # structure.
3. Type or paste your text. The output updates live as you type, with input and output character counts shown below the boxes.
4. Copy the result. Press Copy output to place the encoded or decoded text on your clipboard, or Clear to start over.

5 practical tips for clean URLs

• Encode values, not whole URLs, in code. When building a query string programmatically, run each value through encodeURIComponent and join them yourself; encoding the finished URL with the wrong method is the most common bug.
• Watch out for the ampersand. A raw & inside a value splits your query string into two parameters. If your links behave strangely, an unencoded & is the first suspect.
• Decode before you share. Pasting a decoded URL into docs or chat makes it readable and trustworthy; long % sequences make people hesitate to click.
• Check for double-encoding. If you see %25 in a URL, it was encoded twice. Decode twice to get back to the original text.
• Keep encoded URLs for canonical links. Search engines expect properly encoded canonical URLs, so encode non-ASCII characters in slugs before publishing.

Frequently asked questions