ToolBench

URL Encode / Decode

Encode or decode text as a URL component, a full URI, or application/x-www-form-urlencoded form data — each has slightly different rules for which characters get escaped. Everything runs in your browser; nothing is uploaded.

0 chars0 lines0 bytes
0 chars0 lines0 bytes

What is URL Encode / Decode?

URL Encode / Decode is a browser-based tool that applies percent-encoding to text so it can travel safely inside a URL, and reverses it to recover the original. It offers three flavors — component, full URI, and application/x-www-form-urlencoded form data — because each escapes a slightly different set of characters depending on where the text will be used.

URLs may only contain a limited set of characters, and several of those (like ?, &, =, /, and space) carry special structural meaning. Percent-encoding replaces unsafe or reserved characters with a % followed by their hexadecimal byte value, so a space becomes %20 and an ampersand becomes %26. This is what lets arbitrary text ride safely inside query strings, path segments, and form submissions.

The three flavors matter because encoding a whole URL is different from encoding a single value within it. Component encoding escapes everything that is not safe in a single piece; full-URI encoding leaves the structural characters intact; form encoding follows the rules browsers use for form posts, including turning spaces into +. Everything runs locally — nothing you type is uploaded.

Why use URL Encode / Decode?

Getting URL encoding right prevents a whole class of subtle bugs. A query parameter containing an unencoded & or = silently breaks the URL structure, and an unencoded space can truncate or corrupt a request. This tool encodes text correctly for the exact context you choose, so your links and requests stay valid.

The flavor selector saves you from a common mistake: applying the wrong level of encoding. Encoding an entire URL with component rules destroys its slashes and colons; encoding a single value with full-URI rules leaves reserved characters dangerously unescaped. Choosing component, URI, or form matches the encoding to the job.

Decoding is just as useful for debugging. When you see a percent-encoded string in a log, a redirect, or an address bar, pasting it here reveals the human-readable original. All of this happens in your browser, so URLs containing tokens, session IDs, or personal data never leave your machine — verifiable in the Network tab.

Features

  • Percent-encode text for safe use in URLs
  • Decode percent-encoded text back to its readable form
  • Three flavors: URI component, full URI, and form (x-www-form-urlencoded)
  • Live conversion as you type, including whitespace-only input
  • Clear errors for malformed percent-encoding when decoding
  • One-click copy of the result to your clipboard
  • Download the result as a text file
  • Runs entirely in your browser — no uploads, works offline

How to use URL Encode / Decode

  1. Choose Encode to percent-encode text, or Decode to convert percent-encoded text back.
  2. Select the encoding flavor: component for a single value, URI for a whole URL, or form for form-style data.
  3. Paste or type your text into the input panel on the left.
  4. The result appears in the right panel automatically as you type.
  5. Copy the result to your clipboard, or download it as a text file.

Example 1 — Encode a query value (component)

Component encoding escapes every reserved character so the text is safe as a single query parameter value.

Input

a b/c?d=e

Output

a%20b%2Fc%3Fd%3De

Example 2 — Encode form data (form flavor)

Form flavor follows x-www-form-urlencoded rules, where spaces become + rather than %20.

Input

a b

Output

a+b

Common Mistakes

  • Encoding a whole URL with component rules: this escapes the slashes, colons, and question marks that give the URL its structure, producing a broken string. Use the URI flavor for a complete URL and component only for individual values.
  • Encoding a single value with URI rules: full-URI encoding deliberately leaves reserved characters like & and = alone, so a value containing them will corrupt the surrounding query string. Use component encoding for individual values.
  • Confusing %20 and + for spaces: in form (x-www-form-urlencoded) data a space is +, but in the path or a component it is %20. Decoding a + as a literal plus when it was meant as a space (or vice versa) is a frequent bug.
  • Double-encoding: running already-encoded text through the encoder again turns %20 into %2520. If a string looks over-escaped, it was likely encoded twice — decode once before re-encoding.
  • Malformed percent sequences when decoding: a stray % not followed by two hex digits (like %zz or a lone %) is invalid and causes a decode error. Ensure every % is followed by a valid two-digit hex code.
  • Assuming encoding is encryption: percent-encoding is a transport-safety transform, not security. Anyone can decode it instantly, so never rely on it to hide sensitive values.

Developer Tips

  • Use component encoding (equivalent to JavaScript's encodeURIComponent) for each individual query parameter value, and assemble the full URL yourself — this is the safest default for building URLs.
  • Reach for the form flavor when constructing an application/x-www-form-urlencoded request body by hand, so spaces become + and the encoding matches what servers expect from form posts.
  • When a URL misbehaves, decode it here to inspect the real parameter values — many API bugs come down to a value that was encoded incorrectly or not at all.
  • If you see %25 sequences appearing where you expected a simple %20, you are double-encoding somewhere in your pipeline; decode once to confirm and fix the source.
  • Remember that percent-encoding operates on UTF-8 bytes, so a single non-ASCII character can expand into multiple %XX sequences — that is expected, not a bug.

Frequently Asked Questions

What is the difference between the component, URI, and form flavors?
Component encoding escapes every reserved character, making it safe for a single value inside a URL — it matches JavaScript's encodeURIComponent. URI encoding is for a complete URL and deliberately leaves structural characters like :, /, ?, and & unescaped so the URL still works — it matches encodeURI. Form encoding follows the application/x-www-form-urlencoded rules used for HTML form submissions, where, notably, spaces become + instead of %20. Choose the flavor that matches where the text will actually be used.
Why is a space sometimes %20 and sometimes +?
It depends on the context. In a URL path or a component-encoded value, a space is represented as %20. In application/x-www-form-urlencoded data — the format used for HTML form posts and many query strings — a space is represented as +. Both are correct in their own context, which is why choosing the right flavor matters. Decoding must also match: a + should be turned back into a space only when the data is form-encoded.
What is percent-encoding and why is it needed?
Percent-encoding (also called URL encoding) replaces characters that are unsafe or reserved in a URL with a percent sign followed by the two-digit hexadecimal value of each byte. URLs allow only a limited character set, and characters like &, =, ?, and space have special meaning, so raw text containing them would break the URL. Encoding lets arbitrary text — including spaces, symbols, and non-English characters — travel safely inside URLs and form submissions and be decoded back exactly.
Is my text uploaded when I encode or decode?
No. All encoding and decoding happens locally in your browser using JavaScript. Your text — which may include tokens, session identifiers, or personal data embedded in URLs — is never sent to a server, logged, or stored. You can verify this by opening your browser's Network tab while using the tool: there are zero outbound requests, and it continues to work even offline.
Why does decoding fail with an error?
Decoding fails when the input contains a malformed percent sequence — a % that is not followed by exactly two valid hexadecimal digits, such as %zz or a lone % at the end of the string. Valid percent-encoding always has the form %XX where X is a hex digit. The tool reports a clear error so you can find and fix the bad sequence. Copy the full, unmodified encoded string from its source to avoid truncation or stray characters.
What is double-encoding and how do I avoid it?
Double-encoding happens when already-encoded text is run through the encoder a second time: the % of an existing sequence like %20 gets escaped to %25, producing %2520. This commonly occurs when different layers of a system each encode the same value. To avoid it, encode a value exactly once at the point where it enters the URL. If you see %25 where you expected a simple escape, decode the string once to recover the correctly-encoded form.
Does encoding handle non-English characters?
Yes. Percent-encoding operates on the UTF-8 byte representation of the text, so characters outside the ASCII range — accented letters, emoji, characters from non-Latin scripts — are encoded as one or more %XX sequences, one per byte. This means a single character can expand into several percent sequences, which is expected behavior. Decoding reverses the process and reconstructs the original characters exactly.