URL Encoder / Decoder

How to Use the URL Encoder / Decoder

Select Encode to convert plain text into a URL-safe format, or Decode to convert a URL-encoded string back to readable text. The conversion happens automatically as you type — no button click needed, no form submission required.

To encode a value, paste or type your raw text into the input field and make sure the Encode mode is selected. The tool immediately produces the percent-encoded output, ready to paste into a query string or API request body. To go the other direction, switch to Decode mode and paste in a percent-encoded string such as Hello%20World%21 — the tool converts it back to Hello World! instantly.

When working with non-ASCII text — for instance, Japanese characters, Arabic script, or emoji — each character is first converted to its UTF-8 byte representation, and then each byte is percent-encoded individually. A single emoji can expand into a sequence of six or more percent-encoded bytes. This tool handles that conversion automatically, so you can paste any Unicode text and receive a fully compliant encoded string without thinking about the byte-level details.

If you are building a URL dynamically in code and want to verify that your encoding logic produces the right output, paste your raw value here, compare the result against what your code generates, and check for any discrepancies. This is especially useful when debugging URLs that contain nested query parameters, hash fragments, or characters like &, =, and # that carry structural meaning in a URL.

What is URL Encoding?

URL encoding — formally called percent-encoding and defined in RFC 3986 — is the mechanism for representing arbitrary data within a Uniform Resource Identifier using only the characters that the URI specification permits. The URI syntax divides characters into two categories: unreserved characters (A–Z, a–z, 0–9, -, _, ., ~) which may appear literally, and reserved characters (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =) which have structural roles and must be encoded when they appear as data rather than syntax.

The encoding works by replacing each byte of the character's UTF-8 representation with a triplet: a percent sign followed by two uppercase hexadecimal digits. A space character is a single byte 0x20, so it becomes %20. The euro sign € is three bytes in UTF-8 (0xE2 0x82 0xAC), so it encodes to %E2%82%AC. This means that encoding is not just a character substitution — it is a byte-level transformation that ensures any Unicode text can be safely embedded in a URL regardless of the character set used by the browser or server.

The + encoding for spaces is a separate convention defined by the application/x-www-form-urlencoded media type (used in HTML forms) and is not part of RFC 3986. The two conventions are not interchangeable: a server expecting %20 may misinterpret a literal + as a plus sign, not a space.

Common Use Cases

• Encoding query string parameters — When you append user-supplied data to a URL as a query parameter, characters like & and = would break the parameter structure if left unencoded. For example, a search query of fish & chips must become fish%20%26%20chips so the ampersand is not interpreted as a parameter separator.
• Preparing form data for HTTP POST requests — Form submissions using application/x-www-form-urlencoded encode each field name and value before including them in the request body. Understanding this encoding helps when inspecting network traffic or building raw HTTP requests in test tools like Postman or curl.
• Encoding special characters in API endpoints — REST APIs sometimes include resource identifiers in the URL path that may contain slashes, spaces, or Unicode characters. Path segments need to be encoded so that the routing layer does not confuse data slashes with path delimiter slashes.
• Debugging malformed URLs with encoded characters — When a server returns a redirect URL or a link contains a long string of percent-sequences, decoding it makes the actual content readable in seconds. This saves time compared to manually translating hex values.
• Building dynamic links with user-generated content — Any time you construct a shareable link from data the user typed — a search phrase, a document title, a username — you must encode it to prevent injection of structural characters that could alter the URL's meaning or expose a security vulnerability.

Best Practices & Tips

A few principles will save you from the most common URL encoding bugs in production:

Encode individual values, not entire URLs. Apply encoding only to the data portions — the values of query parameters or path segments — not to the structural characters of the URL itself. Encoding a full URL destroys its structure by turning https:// into https%3A%2F%2F.

Decode before logging for readability. Log files full of percent-encoded strings are hard to read. Decode URL parameters before writing them to logs so that search and pattern matching work against human-readable text. Just make sure you do not log sensitive values in the process.

Watch out for double-encoding. If a value has already been encoded and you encode it again, the percent signs themselves get encoded: %20 becomes %2520. This is one of the trickiest bugs to diagnose because the URL looks almost correct. Before encoding, check whether the string already contains percent-sequences and decode it first if needed.

Use the right function for the right scope. In JavaScript, use encodeURIComponent for individual query parameter values and fragment identifiers. Use encodeURI only when encoding a complete URL that should retain its slashes and colons. Never use the deprecated escape() function — it handles Unicode incorrectly and produces non-standard output.

Test with boundary characters. Always verify your encoding with inputs that contain &, =, #, +, %, and multi-byte Unicode characters. These are the characters most likely to cause silent failures where the URL parses without error but delivers the wrong data.

Related Guides

• URL Encoding Explained — a deeper dive into RFC 3986, percent-encoding, and real-world examples
• For binary data encoding, try our Base64 Encoder
• For encoding HTML special characters like <, >, and &, use our HTML Entity Encoder

FAQ

What is the difference between encodeURI and encodeURIComponent?

This tool uses encodeURIComponent, which encodes all special characters including /, ?, and =. Use it to encode individual query parameter values. encodeURI is used for full URLs and leaves those structural characters intact.

Is my data safe?

Yes. All encoding and decoding happens in your browser. No data is sent to any server.

Why do spaces sometimes become + and sometimes %20?

It depends on the context. In HTML form data encoded as application/x-www-form-urlencoded, spaces are encoded as +. In URL path and query components per RFC 3986, spaces must be encoded as %20. When constructing URLs in JavaScript with encodeURIComponent, you always get %20. The + form is only valid inside form payloads and is not universally accepted in all URL contexts — a server that does not expect form-encoded data will treat + as a literal plus sign, not a space.

What happens if I encode an already-encoded string?

You get double-encoding. For example, %20 becomes %2520 because the percent sign % itself gets encoded to %25. This is a common bug when encoding data in a loop or when encoding is applied at multiple layers of a system — for instance, once in client code and again in a shared utility. Always check whether a string has already been encoded before encoding it again. When in doubt, decode first, then re-encode exactly once.

Do I need to encode the entire URL?

No. You should only encode individual query parameter values and path segments that contain data, not the entire URL. Encoding a full URL converts the slashes, colons, and question marks into percent-sequences, making it unusable as a URL. Use encodeURIComponent for values, and reserve encodeURI for cases where you genuinely need to encode a full URL string while preserving its structural characters.