URL Encoder/Decoder

URLs can only contain a specific set of characters.

When your data includes spaces, special characters, or non-ASCII text, those characters must be percent-encoded before they can appear in a URL. This URL encoder decoder converts text to URL-safe format and decodes percent-encoded strings back to readable text instantly.

Developers work with URL encoding every time they construct query strings, process form submissions, build API calls, or handle redirect URLs. A space becomes %20, an ampersand becomes %26, and a forward slash becomes %2F. Getting the encoding wrong means broken links, failed API calls, or security vulnerabilities. Getting it right means reliable data transmission through URLs.

This tool handles encoding and decoding for both full URLs and individual components (query parameters, path segments, fragment identifiers). Paste text to encode it, or paste an encoded URL to decode it. The tool processes everything in your browser with no data sent to any server.

What Is URL Encoding

URL encoding, also called percent encoding, replaces characters that are not allowed in URLs with a percent sign followed by two hexadecimal digits representing the character’s byte value. For example, a space character (ASCII value 32, hex 20) becomes %20.

URLs are defined by RFC 3986, which specifies which characters are allowed without encoding. Unreserved characters that can appear directly in any URL component include A-Z, a-z, 0-9, hyphen (-), period (.), underscore (_), and tilde (~). Reserved characters like ?, &, =, /, #, and @ have special structural meanings in URLs and must be encoded when used as data rather than as delimiters.

Any character outside the unreserved set must be percent-encoded when it appears as data in a URL. This includes spaces, punctuation marks, non-ASCII characters (encoded as their UTF-8 byte sequences), and reserved characters when they are used as literal data rather than URL structure.

Reserved vs Unreserved Characters

Understanding which characters need encoding depends on where they appear in the URL.

Characters that never need encoding: A-Z, a-z, 0-9, – . _ ~

Characters with reserved meanings in URLs:

  • ? marks the start of the query string
  • & separates query parameters
  • = separates parameter names from values
  • # marks the start of the fragment
  • / separates path segments
  • : separates the scheme from the authority
  • @ separates user info from the host
  • + in query strings represents a space (in the application/x-www-form-urlencoded format)

When these reserved characters appear as data (for example, an ampersand in a company name within a query parameter), they must be encoded. When they appear in their structural role, they must not be encoded.

For example, in the URL https://example.com/search?q=Tom+%26+Jerry, the ? and = are structural and remain unencoded. The & in "Tom & Jerry" is data and must be encoded as %26 to prevent it from being interpreted as a parameter separator.

Common URL Encoding Scenarios

Query string parameters. When passing user input as URL query parameters, all special characters must be encoded. Search queries, form values, and API parameters frequently contain spaces, punctuation, and non-ASCII characters that require encoding.

Redirect URLs. When a URL is passed as a parameter to another URL (common in OAuth flows and tracking redirects), the entire inner URL must be encoded. This prevents the reserved characters in the inner URL from being interpreted as part of the outer URL structure.

API calls. RESTful APIs frequently accept parameters in the URL path or query string. File names, user names, and search terms containing special characters must be encoded to ensure the API server parses them correctly.

Form submissions. HTML forms with method="GET" encode their data into URL query parameters using the application/x-www-form-urlencoded format. This format encodes spaces as + rather than %20, which is a common source of confusion. Both are valid, but the + convention is specific to form-encoded query strings.

Internationalized domain names and paths. Non-ASCII characters in URLs (like accented letters in European languages or CJK characters) must be percent-encoded using their UTF-8 byte representations. The character "e" with an accent requires encoding its multi-byte UTF-8 representation, producing multiple percent-encoded triplets.

Encoding vs Escaping: Key Differences

Developers sometimes confuse URL encoding with other forms of escaping. Each serves a different purpose.

URL encoding (percent encoding) makes data safe for inclusion in URLs. It addresses the URL specification’s character restrictions.

HTML encoding (entity encoding) makes data safe for inclusion in HTML. Characters like <, >, and & are replaced with &lt;, &gt;, and &amp; to prevent them from being interpreted as HTML markup.

JSON encoding escapes characters within JSON strings. Double quotes become \", backslashes become \\, and control characters get Unicode escape sequences.

Base64 encoding converts binary data to ASCII text. See our Base64 Encoder/Decoder for Base64 operations.

Using the wrong encoding for the context causes bugs. HTML-encoding a URL parameter does not make it URL-safe. URL-encoding data inside a JSON string does not make it JSON-safe. Always use the encoding appropriate to the context.

Double Encoding Problems

One of the most common URL encoding bugs is double encoding, where an already-encoded string gets encoded again. The percent sign itself gets encoded, turning %20 into %2520 (the % becomes %25, followed by the literal 20).

Double encoding breaks URLs because the server decodes one layer and receives %20 as a literal string rather than interpreting it as a space. This manifests as URLs that "almost work" but contain visible %XX sequences in the decoded output.

To avoid double encoding, never encode a string that has already been encoded. If you are unsure whether a string is already encoded, decode it first, then encode it once. This tool can help diagnose double encoding by decoding a suspect URL multiple times to see if further decoding produces different results.

The reverse problem, under-encoding, is equally problematic. Forgetting to encode a special character in a query parameter can cause the server to misparse the URL, splitting parameters incorrectly or truncating values at unencoded reserved characters.

URL Encoding in JavaScript

JavaScript provides two pairs of encoding and decoding functions with different scopes.

encodeURIComponent() / decodeURIComponent() encodes everything except A-Z, a-z, 0-9, and – _ . ! ~ * ‘ ( ). This is the correct function for encoding individual URL components like query parameter values. It encodes reserved characters including /, ?, &, =, and #.

encodeURI() / decodeURI() encodes everything except unreserved characters AND reserved characters that form URL structure (/, ?, #, &, =, :, @, +). This function is designed for encoding a complete URL while preserving its structure. It should not be used for encoding individual components.

The distinction matters. Using encodeURI() on a query parameter value will fail to encode & and =, potentially breaking the query string structure. Using encodeURIComponent() on a complete URL will encode the slashes and colons, breaking the URL structure. Use the right function for the right context.

For related developer tools, see our JSON Formatter for working with API response data and our Regex Tester for building URL validation patterns.

Frequently Asked Questions

What is URL encoding?

URL encoding (percent encoding) replaces characters not allowed in URLs with a percent sign followed by their hexadecimal byte value. For example, a space becomes %20, an ampersand becomes %26. This ensures special characters are transmitted safely in URLs.

Why do spaces sometimes appear as + and sometimes as %20?

Both represent spaces in URLs, but in different contexts. The + convention is specific to the application/x-www-form-urlencoded format used by HTML form submissions. The %20 encoding is the universal percent-encoding standard defined by RFC 3986.

Which characters need URL encoding?

Any character that is not in the unreserved set (A-Z, a-z, 0-9, -, ., _, ~) should be encoded when used as data in a URL. Reserved characters like ?, &, =, and # must be encoded when they appear as literal data rather than URL structure.

What is double encoding and how do I fix it?

Double encoding occurs when an already-encoded string is encoded again, turning %20 into %2520. Fix it by decoding the string fully, then encoding once. Never encode a string that is already encoded.

Should I use encodeURI or encodeURIComponent in JavaScript?

Use encodeURIComponent() for encoding individual values like query parameters. Use encodeURI() for encoding a complete URL while preserving its structure. Using the wrong function causes broken URLs.

How are non-English characters encoded in URLs?

Non-ASCII characters are first converted to their UTF-8 byte representation, then each byte is percent-encoded. A single character may produce multiple percent-encoded triplets depending on the number of UTF-8 bytes.

Is URL encoding the same as HTML encoding?

No. URL encoding uses percent signs (%20, %26) for URL-safe data transmission. HTML encoding uses entity references (&amp;, &lt;) for safe HTML display. They serve different purposes and are not interchangeable.

Data accurate as of: March 2026