Free URL Encoder Decoder Online - Percent Encoding Tool

A This tool is designed for efficiency! You can paste multiple distinct URL path segments or query parameter values (each on a new line) into the encoder. It will process each line independently, converting special characters into their correct percent-encoded format. This saves significant time when preparing numerous new URLs for sitemaps, internal links, or API calls, ensuring all links are valid and robust from day one of your launch.

A This tool focuses on URL encoding, not character set conversion. It assumes your input text is already in a standard set like UTF-8. If you have text in a different encoding, you'll need to convert it to UTF-8 first before using this encoder to ensure proper percent-encoding. For example, if you have a string with non-ASCII characters, make sure it's represented as UTF-8 bytes before feeding it here.

A encodeURI is meant for encoding whole URLs, not parameter values. It preserves characters with special meaning in URLs — like ?, #, /, and =. Use encodeURIComponent instead if you need those characters encoded. For example, encodeURI leaves ? alone, but encodeURIComponent turns it into %3F. Pick the right mode in this tool based on what part of the URL you're encoding.

A Browsers often normalize URLs automatically. For example, typing a space in the address bar gets converted to %20, but some browsers display it as a space again. Our tool shows you the raw percent-encoded output, which is what actually gets sent over the network. Paste your browser's address into the decoder to see the real underlying characters. This mismatch catches many developers off guard.

A Yes, they're completely different systems. URL encoding turns spaces into %20, while HTML entity encoding uses   or   for spaces. Mixing them up breaks links and displays raw codes on pages. Use this tool for URL encoding only. If you're debugging JSON API responses and see & instead of &, that's HTML encoding leaking in, not a URL problem.

A Double-encoding happens when someone encodes an already percent-encoded string. You'll see stuff like %2520 instead of %20. Run it through the decoder once, check if the result still has percent signs, then decode again if needed. Three passes is almost never necessary. If you're debugging a payment gateway callback that looks garbled, this is usually the culprit.

A No, not at all. URL encoding is just about formatting — it turns spaces into %20 and special characters into percent codes. Anyone can decode it instantly with this same tool. Think of it like wrapping a sandwich in clear plastic: it's neat but totally see-through. If you're sharing sensitive info like passwords or API keys in URLs, use real encryption (HTTPS covers transport) or hash them instead. Encoding alone offers zero privacy.

A Email editors often auto-encode spaces and special characters, but inconsistently. Your link might have a raw space that looks fine in the editor but turns into %20 only after sending — or worse, gets truncated at the first space. Paste your newsletter link into this decoder first to see what characters it actually contains. If you spot a lone `&` instead of `&`, that's HTML encoding, not URL encoding. A quick tip: encode the entire query string with `encodeURIComponent` before inserting it into your newsletter template. Most email clients handle percent-encoded URLs just fine.

A The decoder will just show you the original percent-encoded bytes, nothing more. For example, `%2520` decodes to `%20` on the first pass, not a space. Run it through again if you suspect double-encoding — that second pass is where you'll finally see a space. I've seen data pipelines accidentally triple-encode query strings, so check twice if your API logs look odd. A quick tip: if you're cleaning spreadsheet exports, decode once, then grep for remaining `%` signs to spot leftovers.

A No, and mixing them up causes real headaches. URL encoding uses percent signs followed by hex values — a space becomes %20. Base64 uses a completely different alphabet of A-Z, a-z, 0-9, plus, and slash to pack binary data into text. Try decoding a base64 string here and you'll get garbage or an error. Need to spot the difference? Base64 strings often end with = padding and are way longer than their source. If you're building signed links for an API, check the docs carefully: some systems expect base64url, which swaps + and / for - and _. That variant won't decode properly in our tool either.