Encoding Tool

URL Encoder & Decoder

Encode special characters for URLs or decode percent-encoded strings back to readable text.

0 characters

URL Encoding: The Complete Guide to Percent-Encoding for the Web

URL encoding, also known as percent-encoding, is a mechanism for converting characters into a format that can be safely transmitted over the internet. URLs are designed to carry a limited set of ASCII characters — letters, digits, and a few special symbols like hyphens and underscores. When you need to include characters outside this safe set (spaces, accented letters, emojis, or characters with special meaning like & and ?), they must be encoded as percent-sign followed by two hexadecimal digits representing the character's byte value.

Without URL encoding, the web as we know it would not function. Search queries containing spaces, international characters in domain names, complex filter parameters with special symbols, and any user-generated content that appears in a URL all rely on percent-encoding to work correctly. A space character becomes %20, an ampersand becomes %26, and an emoji might expand to a sequence of multiple percent-encoded byte values. Understanding how this encoding works is essential for anyone building web applications, consuming APIs, or debugging URL-related issues.

Our URL Encoder & Decoder tool provides instant, accurate conversion between plain text and URL-encoded format. Whether you are constructing API requests, debugging query parameters, or working with web hooks, this tool handles the encoding and decoding correctly — including Unicode characters, special symbols, and reserved characters. All processing happens locally in your browser for maximum speed and privacy.

How Percent-Encoding Works

Percent-encoding operates on a simple principle: any byte that is not an unreserved character (A-Z, a-z, 0-9, hyphen, period, underscore, tilde) is represented as a percent sign (%) followed by two hexadecimal digits. The hexadecimal digits correspond to the byte's value in the character encoding (typically UTF-8 for web content). This mechanism is standardized in RFC 3986 and is implemented consistently across all web browsers, servers, and HTTP libraries.

The encoding process:

Unreserved characters (never encoded): A-Z, a-z, 0-9, - (hyphen), . (period), _ (underscore), ~ (tilde). These characters have no special meaning in URLs and are always safe to use as-is.

Reserved characters (encoded when used as data): !, #, $, &, ', (, ), *, +, ,, /, :, ;, =, ?, @, [, ]. These characters have syntactic meaning in URLs. When they appear as data (not as URL delimiters), they must be percent-encoded.

Non-ASCII characters (always encoded): Characters outside the ASCII range (accented letters, CJK characters, emojis) are first encoded as UTF-8 bytes, and then each byte is percent-encoded. For example, the euro sign (€) is encoded as %E2%82%AC because its UTF-8 representation is the three bytes E2, 82, AC.

Space character: Spaces must be encoded in URLs. The standard encoding is %20, but in query strings, spaces are sometimes encoded as + (plus sign). Our tool uses the %20 standard, which is correct for all URL components.

URL Encoding in Query Strings and Parameters

Query strings are the most common place where URL encoding is needed. A query string appears after the ? in a URL and consists of key-value pairs separated by & characters. The challenge is that many of the characters used as delimiters in query strings (&, =, ?) are also common in user input. Without proper encoding, these characters would break the URL structure and cause incorrect parameter parsing on the server side.

Query string encoding examples:

  • Search query with spaces: "hello world" becomes "hello%20world" in the URL parameter. Without encoding, the space would terminate the URL.
  • Value containing &: The company name "A&B Corp" must be encoded as "A%26B%20Corp" to prevent the & from being interpreted as a parameter separator.
  • JSON in parameters: Passing JSON as a URL parameter requires encoding all special characters: braces, quotes, colons, and commas all need percent-encoding.
  • Multiple values: Arrays and complex data structures can be encoded using conventions like "key[]=value1&key[]=value2" or "key=value1,value2", each requiring careful encoding of brackets and commas.

A common mistake is double-encoding — encoding a value that has already been encoded. This happens when URL construction code encodes a parameter, and then the HTTP library encodes the entire URL again. The result is that %20 becomes %2520 (the % sign itself gets encoded as %25). Always encode parameter values once, and let your HTTP library handle the overall URL construction. Our decoder can help you identify and fix double-encoding issues by showing you the raw decoded output.

URL Encoding in Web APIs and Integrations

When building or consuming web APIs, URL encoding is not optional — it is a fundamental requirement for correct operation. API endpoints that accept parameters in the URL path or query string must have those parameters properly encoded, or the server will misinterpret the request. This is especially critical for REST APIs, OAuth flows, and webhook integrations where URLs carry authentication tokens, user input, and configuration data.

API Encoding Scenarios

  • • OAuth redirect URLs with state parameters
  • • REST API paths containing resource IDs with special characters
  • • Webhook callback URLs with custom parameters
  • • Search API queries with user-generated content
  • • API keys and tokens in URL parameters
  • • Pagination cursors and filter expressions

Common API Mistakes

  • • Forgetting to encode path segments (not just query params)
  • • Double-encoding values already encoded by the HTTP library
  • • Using encodeURI when encodeURIComponent is needed
  • • Not encoding + signs in OAuth signatures
  • • Assuming the HTTP library handles all encoding automatically
  • • Encoding the entire URL instead of individual components

Common Characters That Need URL Encoding

While any non-ASCII or reserved character needs encoding, certain characters come up far more frequently in practice. Knowing which characters commonly require encoding helps you quickly identify encoding issues and construct URLs correctly without relying solely on automated tools. Here is a comprehensive reference of the most commonly encoded characters and their percent-encoded equivalents.

Frequently encoded characters reference:

Space → %20

& → %26

= → %3D

? → %3F

/ → %2F

# → %23

% → %25

+ → %2B

@ → %40

: → %3A

; → %3B

, → %2C

Common URL Encoding Pitfalls and How to Avoid Them

URL encoding seems straightforward, but subtle mistakes can cause frustrating bugs that are difficult to diagnose. These issues often don't appear during development with simple test data but surface in production when users submit content with special characters, international text, or unusual formatting. Understanding the most common pitfalls helps you write more robust code and debug encoding issues faster when they occur.

Top encoding pitfalls:

  • Double encoding: Encoding an already-encoded string produces %25 in place of %, creating invalid URLs. For example, %20 becomes %2520. Always check whether data has already been encoded before encoding it again.
  • Wrong encoding function: Using encodeURI when you need encodeURIComponent (or vice versa) leads to incorrectly encoded URLs. encodeURI preserves URL structure characters like /, ?, and &, while encodeURIComponent encodes everything.
  • Space handling inconsistency: Some systems use + for spaces in query strings while others use %20. Mixing these conventions can cause mismatches between what your client sends and what the server expects.
  • Character encoding mismatch: If the client and server disagree on character encoding (UTF-8 vs. Latin-1), percent-encoded bytes will be decoded to wrong characters. Always use UTF-8 for web content.
  • Path vs. query encoding: Path segments and query parameters have different encoding rules. The / character is valid in a path but must be encoded in a query parameter value. Using the wrong encoding for the wrong URL component breaks the URL structure.

encodeURI vs encodeURIComponent: When to Use Each

JavaScript provides two URL encoding functions, and choosing the wrong one is one of the most common sources of encoding bugs. The key difference is that encodeURI preserves characters that have structural meaning in a complete URL, while encodeURIComponent encodes everything that isn't an unreserved character. Using the right function for the right context is essential for constructing valid URLs.

encodeURI (Full URLs)

  • • Preserves: / ? & = + : @ # $ , ;
  • • Use when: Encoding a complete URL
  • • Don't use for: Individual parameter values
  • • Example: encodeURI("https://example.com/path?q=test")
  • • Keeps the URL structure intact

encodeURIComponent (Components)

  • • Encodes: All reserved characters including / ? & = + :
  • • Use when: Encoding a single parameter value
  • • Don't use for: Complete URLs (breaks structure)
  • • Example: encodeURIComponent("a&b") → "a%26b"
  • • Safest choice for individual values

Our tool uses encodeURIComponent for encoding, which is the correct and safe choice for encoding individual values that will be embedded in URLs. If you need to encode a complete URL (preserving its structure), you should use encodeURI instead. When in doubt, use encodeURIComponent — it is always safe for encoding parameter values, and most encoding bugs come from under-encoding rather than over-encoding.