URL Encoder Decoder

The URL Encoder converts text and special characters into percent-encoded format — the web-safe representation required for transmitting data inside URLs. The URL Decoder reverses the process, converting percent-encoded sequences back to readable text. Paste any URL, query string, parameter value, or text into the input field, choose Encode or Decode, and the tool produces the converted output instantly.

Percent-encoding is the standard mechanism defined in RFC 3986 (Uniform Resource Identifier syntax) for representing characters that are either unsafe or have reserved structural meaning in URLs. Without it, a URL containing a space, an ampersand, or a non-ASCII character would be ambiguous — different parsers would interpret the same URL in different ways, producing broken links, failed API requests, and corrupted data. Understanding which characters require encoding and when is a fundamental web development and SEO skill.

How to use the URL Encoder / Decoder

1. Paste the text or URL you want to convert into the input field.

2. Select Encode to convert special characters to percent-encoding, or Decode to convert percent-encoded sequences back to plain text.

3. Click Generate to produce the output.

4. Copy the result and use it in your API request, link builder, redirect configuration, analytics tool, or code.

Encode only the parts of a URL that contain data — not the structural elements. A complete URL such as https://example.com/search?q=blue shoes&category=men should have the parameter values encoded (blue%20shoes, not the entire URL. Encoding the structural characters (the colon after https, the double slash, the question mark, the ampersand between parameters) turns them into data characters and breaks the URL structure. Use encodeURIComponent() when encoding individual values in code, and use the full-URL encoder for entire URLs that already have correct structure but contain non-ASCII characters in path or query segments.

How percent-encoding works — the RFC 3986 standard

Percent-encoding replaces an unsafe or reserved character with a percent sign (%) followed by the two-digit hexadecimal representation of the character's byte value in UTF-8. A space has the ASCII code 32, which in hexadecimal is 20 — hence the familiar %20. The at sign @ has code 64 (hex 40) — hence %40. For non-ASCII characters, the character is first encoded as UTF-8 bytes, and each byte is then percent-encoded individually.

Encoding examples

space -> %20

& -> %26

= -> %3D

? -> %3F

/ -> %2F

# -> %23

% -> %25

e (accented) -> %C3%A9 (UTF-8 bytes: C3, A9)

(c) symbol -> %C2%A9 (UTF-8 bytes: C2, A9)

Character classes — what to encode and what to leave unchanged

Common encoded characters — complete reference

The + character has different meanings in different URL contexts — this is one of the most common sources of URL encoding bugs. In HTML form encoding (application/x-www-form-urlencoded, used by GET forms), a + represents a space. In path segments and in strict percent-encoding, + is a literal plus sign. If a parameter value contains a literal + that should remain a plus sign in the decoded form, encode it as %2B — not as + — to prevent form parsers from decoding it as a space. Conversely, if you receive a URL-encoded string where + represents a space and you need to decode it, replace + with a space before applying percent-decoding.

Double encoding — what it is and how to prevent it

Double encoding occurs when a value that has already been percent-encoded is encoded again. The result is that percent signs themselves become encoded: the already-encoded %20 (a space) is encoded a second time to %2520 (because % encodes to %25, and 20 remains as 20). The receiving server decodes %2520 to %20 — a literal string of three characters, not a space — which is incorrect.

Double encoding anatomy

Original value: hello world

Correctly encoded: hello%20world

Double-encoded: hello%2520world

When decoded once: hello%20world (not the original)

When decoded twice: hello world (original recovered, but broke the first time)

Double encoding typically occurs when: a developer encodes a value that was already received in encoded form, a build tool or framework applies encoding to a value that the developer also encoded manually, or a redirect configuration encodes a destination URL that is already percent-encoded.

If you see %25XX in a URL (where XX is any two hex digits), the URL has been double-encoded. If you see %252520, it has been triple-encoded. To fix double encoding: decode the string once using the URL Decoder, then verify the result is the correct unencoded value before re-encoding if necessary. The URL Decoder tool on this page performs exactly one decoding pass — submit the double-encoded string once, verify the output shows single-encoded %XX sequences, then submit again to decode to the original plain text.

encodeURI versus encodeURIComponent — JavaScript reference

JavaScript provides two built-in functions for URL encoding. Understanding the difference is essential for writing correct URL construction code.

The practical rule: always use encodeURIComponent() when encoding individual parameter values before adding them to a query string. Use encodeURI() only when encoding a complete URL that is already correctly structured and simply needs non-ASCII characters or spaces handled. Never apply encodeURI() to a parameter value that contains & or = — it will not encode them, leaving the query string parser to misinterpret them as delimiters.

Real-world encoding scenarios

Usage limits

Related tools

• Meta Tag Analyzer — inspect meta tags on any page. When diagnosing SEO issues caused by malformed URLs in canonical tags, hreflang attributes, or sitemap entries, the Meta Tag Analyzer reads the raw tag values including any percent-encoded characters. Use alongside the URL Decoder to verify that encoded characters in tag values represent the correct underlying URLs.

• HTML Minifier — compress HTML for faster delivery. Inline JavaScript that constructs URLs programmatically should use encodeURIComponent() for parameter values. Minifying the HTML after verifying URL construction logic is correct is the recommended workflow — minification preserves string content exactly, so any encoding errors in the source will be present in the minified output.

• Get HTTP Headers — verify HTTP response headers for any URL. When troubleshooting redirect chains involving percent-encoded URLs, the Get HTTP Headers tool shows the exact Location header value returned by the server — including whether the redirect destination URL is correctly or incorrectly encoded. Use this to confirm that redirect rules are preserving or re-encoding URL parameters as intended.

Frequently asked questions

What is URL encoding and why is it necessary?

URL encoding (formally called percent-encoding, defined in RFC 3986) is the process of converting characters that are not safe or not permitted in URLs into a web-safe representation. A URL can only contain a specific set of characters — the 26 upper and lower case ASCII letters, the digits 0–9, and a small set of special characters (-_.~). All other characters — spaces, accented letters, non-Latin scripts, and the characters that have reserved structural meaning in URLs (&, =, ?, /, #, :) — must be represented as a percent sign followed by their hexadecimal UTF-8 byte value. Without encoding, a URL containing a space, a Chinese character, or an ampersand inside a parameter value would be ambiguous and would be parsed incorrectly by different browsers, servers, and tools.

What is the difference between %20 and + for encoding spaces?

Both %20 and + represent a space in URL-encoded strings, but they are valid in different contexts. %20 is the RFC 3986 standard percent-encoding of a space and is valid in any URL component — path segments, query strings, fragment identifiers. The + character as a space representation is specific to the application/x-www-form-urlencoded format, which is the encoding used by HTML forms submitted with method='GET'. In this context, form field values have spaces encoded as + rather than %20. Outside of form-encoded query strings, + means a literal plus sign. This distinction matters when building URLs programmatically: use %20 for spaces in all contexts unless you are specifically building a form-encoded query string, in which case + is also valid. If a URL contains + and you are uncertain whether it means space or literal plus, check the encoding context — URL Decoding will always treat %20 as a space, but may not treat + as a space unless the decoder specifically handles form encoding.

What does %2520 in a URL mean and how do I fix it?

The sequence %2520 in a URL indicates double encoding. The value was percent-encoded twice. %25 is the percent-encoding of a literal % character, and 20 is the hex value for a space — so %2520 decodes once to %20, and %20 decodes a second time to a space. The original value was a space that was correctly encoded as %20, but then that encoded string was encoded again, turning the % in %20 into %25 and producing %2520. To fix double encoding: decode the URL once using the URL Decoder. If the output still contains %XX sequences where plain text was expected, decode again. Identify where in the code or configuration the encoding is being applied twice and remove the duplicate encoding step. In JavaScript, a common cause is calling encodeURIComponent() on a value that was already encoded — or building a URL string and then calling encodeURIComponent() on the entire URL rather than on individual parameter values.

Should I encode the entire URL or just the parameter values?

For almost all use cases, encode only the parameter values — not the entire URL structure. The structural parts of a URL (the protocol https://, the double slash after it, the domain, the forward slashes between path segments, the ? that starts the query string, and the & that separates parameters) should not be encoded. Encoding them transforms structural syntax into data characters and breaks the URL. The parts that should be encoded are the values after each = sign in the query string, and any path segment that contains characters outside the unreserved set. The exception is when an entire URL must be embedded as a value inside another URL — for example, a redirect destination URL passed as a query parameter: ?next=https%3A%2F%2Fexample.com%2Fdashboard. In this case, the entire inner URL is a data value and must be fully encoded, including its structural characters.

Why does my URL break when it contains non-English characters?

Non-ASCII characters — accented Latin letters, Chinese, Japanese, Korean, Arabic, Cyrillic, emoji — are not valid in the raw form inside URLs. They must be represented as their UTF-8 byte sequence with each byte percent-encoded. A multi-byte character typically produces two or three percent-encoded sequences. For example, the Chinese character for 'China' (zh: 中, Unicode U+4E2D) has the UTF-8 byte sequence E4 B8 AD and is encoded as %E4%B8%AD. Modern browsers display the decoded Unicode character in the address bar for readability — but the URL transmitted in the HTTP request header always uses the percent-encoded form. If a URL containing non-ASCII characters is breaking in a specific tool, email client, or analytics platform, use the URL Encoder to produce the fully percent-encoded version of the URL for use in that context.

What is the difference between encodeURI and encodeURIComponent in JavaScript?

Both are built-in JavaScript functions for percent-encoding, but they encode different sets of characters. encodeURI() encodes characters that are completely invalid in URLs (spaces, non-ASCII) but leaves all characters that have structural meaning in URLs unencoded — including &, =, ?, /, #, and :. This makes it safe to apply to a complete, already-structured URL without breaking it. encodeURIComponent() encodes everything except the unreserved characters (letters, digits, hyphen, underscore, period, tilde), including all the reserved structural characters. This makes it the correct function to use when encoding an individual parameter value before embedding it in a query string — it ensures characters like & and = inside the value are encoded and will not be misinterpreted as query string delimiters. The practical rule: use encodeURIComponent() for values, encodeURI() for complete URLs.

How do I decode a URL that contains %XX sequences?

Paste the percent-encoded URL or string into the URL Decoder input field and click Decode. The tool replaces each %XX sequence with the corresponding character. For multi-byte UTF-8 characters encoded as consecutive %XX sequences (such as %E4%B8%AD for a Chinese character), the decoder interprets the byte sequence and produces the correct Unicode character. If the decoded output contains further %XX sequences, the original string may have been double-encoded — decode it a second time to recover the original plain text. In JavaScript, the equivalent function is decodeURIComponent() for parameter values or decodeURI() for complete URLs. Note that decodeURIComponent() will throw an error if the input contains a malformed percent sequence (% followed by non-hex characters or by fewer than two characters) — the ToolsPiNG decoder handles malformed sequences gracefully without throwing an error.

Is the URL Encoder / Decoder free?

Yes. The tool is free within the daily usage limits. Guest users can encode or decode 25 strings per day. Registering a free ToolsPiNG account increases the limit to 100 per day. For programmatic encoding and decoding at scale — processing large numbers of URLs in a build pipeline, analytics data processing, or server-side log analysis — the JavaScript built-in functions encodeURIComponent() and decodeURIComponent() (or their equivalents in Python: urllib.parse.quote() and urllib.parse.unquote()) are the appropriate tools, as they can be applied to any volume of data without a daily limit.