Local Tools Online

URL Encoder / Decoder

Convert text to and from percent-encoding (also called URL encoding) for safe use in query strings, path segments, and form data. Runs entirely client-side using your browser’s native encoding functions.

Why URL encoding trips people up

URLs can technically only contain a limited set of ASCII characters safely. Spaces, ampersands, question marks, non-Latin characters, emoji — anything outside that safe set needs to be represented using %XX percent-encoding, where XX is the hex value of the byte. This becomes a real problem the moment you’re:

  • Building a query string by hand and your search term contains a &, which the browser will otherwise interpret as a new parameter, silently breaking your URL
  • Passing a URL as a parameter inside another URL (like a redirect URL), which needs to be encoded so the outer URL parser doesn’t choke on it
  • Debugging a webhook or API request where a parameter with special characters isn’t arriving the way you expect
  • Working with non-English text in URLs, where every non-ASCII character expands into multiple percent-encoded bytes

Getting this wrong produces bugs that are maddening to track down because the URL often looks fine in a browser address bar (which auto-corrects a lot of this for you) but fails when constructed programmatically or passed through an API.

How to use it

  1. Choose Encode or Decode mode.
  2. Paste your text or URL into the input field.
  3. The tool shows the converted output immediately, along with a breakdown of which specific characters were encoded and why (reserved character, non-ASCII, or unsafe character) if you expand the details panel.
  4. There’s a toggle between component encoding (encodes everything including /, ?, & — for encoding a value that will go inside a query parameter) and full URL encoding (leaves URL-structural characters like /, :, ? alone — for encoding a complete URL you intend to keep navigable).
  5. Copy the result, or click “encode again” to see double-encoding in action if you’re debugging a double-encoding bug (a very common source of broken links).

Common situations this solves

  • Building query strings with user input that might contain spaces, symbols, or punctuation, without breaking the URL structure.
  • Debugging “why does this link 404” issues caused by unencoded special characters in a path or query parameter.
  • Passing a callback or redirect URL as a parameter, which needs its own internal ? and & characters encoded so they don’t collide with the outer URL’s parameters.
  • Decoding a URL from server logs or analytics data to read the actual query parameters a user submitted.
  • Working with international domain names or non-Latin search terms in URLs, where encoding is mandatory rather than optional.

Frequently asked questions

What’s the difference between encodeURI() and encodeURIComponent()? This is the most common confusion in URL encoding. encodeURI() (full URL encoding) is meant for encoding an entire URL and leaves structural characters like /, :, ?, and & untouched, since removing them would break the URL. encodeURIComponent() (component encoding) is meant for encoding a single value that will be inserted into a URL, so it encodes those same structural characters too, treating them as literal data rather than structure. Use component encoding for query parameter values; use full encoding only when handling a complete URL string.

Why do I sometimes see %2520 instead of %20? This is double-encoding — a value got percent-encoded twice, so the % from the first encoding pass (which itself becomes %25) got encoded again on a second pass. It usually happens when a URL is encoded once by your code and again automatically by a framework or browser. Decoding twice will get you back to the original.

Does this handle emoji and non-Latin characters? Yes. Since URLs work at the byte level, characters outside basic ASCII (emoji, Chinese characters, accented letters, etc.) get converted to their UTF-8 byte representation first, then each byte is percent-encoded, which is why a single emoji can turn into a surprisingly long string of %XX sequences.

Is + the same as %20 for encoding spaces? Not quite — they’re both used for spaces but in different contexts. %20 is the standard percent-encoding for a space and is correct in URL paths. + for spaces is a legacy convention specific to application/x-www-form-urlencoded form submissions (query strings from HTML forms), and using + outside that context can cause it to be misinterpreted as a literal plus sign.

Why does my URL still not work after encoding it? Check whether you encoded the whole URL when you should have only encoded a specific parameter’s value (or vice versa) — this is the single most common mistake, and the component vs. full encoding toggle on this tool is built specifically to help you spot it.