URL Encoder / Decoder

EncodeDecode
Success
No Output Yet

Enter some text above to see the encoded results.

Percent-Encoding Mechanics: How RFC 3986 Translates Unsafe Characters

Uniform Resource Identifiers (URIs) depend on a restricted set of US-ASCII characters to guarantee dependable transmission across web servers, proxies, and client browsers. When a web address contains characters outside this allowed set, or includes characters with reserved syntactic roles, standard percent-encoding transforms those bytes into a safe triplet format.

The mechanism operates at the byte level. Each character outside the unreserved character set converts into its underlying UTF-8 byte sequence. The encoder replaces each byte with a percent symbol (%) followed by two hexadecimal digits representing the byte value. For instance, a standard space character has a decimal ASCII code of 32, which translates to hexadecimal 20, producing %20 in the final URL.

Multi-byte international characters and symbols follow the exact same rule across their full byte representation. The character ü occupies two bytes in UTF-8 (hexadecimal C3 and BC), producing %C3%BC. Modern search engine crawlers and HTTP parsers require this strict octet representation to process international domain paths and UTF-8 query parameters without losing data.

Character Classification in Uniform Resource Identifiers

RFC 3986 divides all characters into unreserved characters and reserved characters. Unreserved characters never need encoding because they carry no structural meaning in URI grammar. Reserved characters serve as syntax boundaries, such as separating the host from the path or delimiting individual query parameters. When a reserved character is part of the actual data payload rather than a structural boundary, you must percent-encode it.

The unreserved character set consists of uppercase letters (A-Z), lowercase letters (a-z), decimal digits (0-9), hyphens (-), underscores (_), periods (.), and tildes (~). All other characters, including whitespace, control characters, and reserved delimiters, require percent-encoding when used inside query values or path segments.

RFC 3986 Reserved and Unsafe Character Reference

Common reserved characters, their percent-encoded equivalents, and how unencoded data disrupts HTTP parsers.

CharacterNameRFC 3986 HexURI ClassificationParser Impact If Unencoded
SpaceSpace%20Unsafe whitespaceBreaks request line parsing and triggers HTTP 400 Bad Request errors
&Ampersand%26Sub-delimiterPrematurely splits query strings into multiple unintended parameters
=Equal sign%3DSub-delimiterBreaks key-value parameter pairing syntax
?Question mark%3FGeneral delimiterStarts a new query string prematurely and disrupts URL routing
#Number sign (hash)%23General delimiterMarks start of fragment; servers drop all trailing characters
/Forward slash%2FGeneral delimiterCreates false path hierarchies and breaks endpoint matching
:Colon%3AGeneral delimiterConfuses port number, scheme, or auth credential boundaries
+Plus sign%2BSub-delimiterDeserialized into an empty space by form-urlencoded parsers
%Percent sign%25Escape prefixCauses invalid percent-escape errors or double-encoding defects
@At sign%40General delimiterInterpreted as userinfo credential boundary in URI authorities

The Space Character Dilemma: %20 Versus the Plus (+) Sign

One of the most frequent sources of data corruption in web APIs is the confusion between %20 and the plus sign (+). RFC 3986 specifies %20 as the universal percent-encoded representation of a space character across the entire URI, including path segments and query components.

In contrast, the plus sign convention comes from the W3C HTML form specification under the MIME media type application/x-www-form-urlencoded. In standard web forms, browser engines replace spaces with plus signs before submitting form fields. Many backend web frameworks, including Express, Spring, Django, and PHP, automatically decode a plus sign in a query string into an empty space.

This dual behavior causes bugs when handling literal plus signs. If an API endpoint receives an email alias like dev+updates@domain.com or a phone number like +14155552671 without encoding the plus sign as %2B, the receiving server decodes the plus sign as a space, producing dev updates@domain.com and invalidating the request data.

Component Encoding vs. Full URI Encoding in Production Code

Developers building web applications frequently encounter defects by using the wrong encoding method for their data context. JavaScript provides two native functions, encodeURI() and encodeURIComponent(), each designed for a different architectural task.

Full URL Corruption via encodeURIComponent()Target URL: https://api.slokee.com/v1/search?query=hello worldIncorrect Call: encodeURIComponent(targetUrl)Result: https%3A%2F%2Fapi.slokee.com%2Fv1%2Fsearch%3Fquery%3Dhello%20worldOutcome: Fails connection because protocol slashes (://) become escaped text.
Query Parameter Truncation via encodeURI()Parameter Value: sales&marketing=trueIncorrect Call: '/search?category=' + encodeURI(value)Result: /search?category=sales&marketing=trueOutcome: Server parser splits input into two keys: category='sales' and marketing='true'.

Use encodeURI() when preparing an entire URL string with existing path structures and query delimiters that must remain intact. Use encodeURIComponent() when handling individual query parameter values or route variables. In modern client and Node.js code, constructing query strings with URLSearchParams handles these distinctions automatically.

Troubleshooting Double Encoding and Gateway Deserialization Errors

A common bug in microservice architectures and reverse proxy setups is double encoding. This happens when an already percent-encoded value passes through a second encoding pass. Because the percent symbol (%) is itself an active escape prefix with hex value 25, the secondary encoder converts %20 into %2520, and %26 into %2526.

Intermediate proxies, API gateways (such as Nginx, AWS CloudFront, or Cloudflare), and load balancers often normalize incoming request paths before forwarding them upstream. If a gateway decodes a path segment once, but your downstream application expects raw encoded data, routing mismatches and signature verification failures in HMAC or OAuth2 headers occur.

Our client-side URL Encoder and Decoder helps you isolate these issues instantly. By inspecting and toggling your string between encoded and decoded formats right in your browser, you verify whether your API payloads match RFC 3986 requirements before dispatching network requests.

Clear answers on percent-encoding, RFC 3986 standards, query strings, and character handling.

URL Encoder & Decoder: Frequently Asked Questions

RFC 3986 defines percent-encoding as a format to represent characters outside the standard US-ASCII set within a URI. The encoder converts each reserved or unsafe character into a percent sign followed by two hexadecimal digits that represent the byte value in UTF-8 format.
RFC 3986 sets %20 as the official standard for space characters across all URI components. The plus sign (+) originated in the HTML form specification (application/x-www-form-urlencoded). While many backend query parsers accept plus as a space in query strings, path segments require %20. Modern web applications prefer %20 to prevent ambiguity.
encodeURI encodes a complete URL while keeping structural delimiters like ://, ?, #, and / intact. encodeURIComponent encodes individual parameter values and escapes delimiters like &, =, and ?. Use encodeURIComponent for query values and encodeURI only when sanitizing an entire URI structure.
A double encoding bug happens when a percent-encoded string is run through an encoder a second time. The percent symbol (%) gets converted into %25, turning %20 into %2520. To avoid this, encode values once at the point of origin and avoid re-encoding strings passed through reverse proxies or intermediate microservices.
UTF-8 represents non-ASCII characters and symbols using two to four bytes. The encoder converts each individual byte into a two-character hex sequence preceded by a percent sign. For instance, the letter é converts into two bytes (%C3%A9), and the rocket emoji (🚀) becomes four bytes (%F0%9F%9A%80).
Web servers that follow form-encoding rules automatically decode plus signs into spaces in query strings. If your query parameter contains a legitimate plus sign, such as in an international phone number (+14155552671) or email tag, you must encode the plus sign as %2B before sending the request.
RFC 3986 specifies that uppercase letters (A-Z), lowercase letters (a-z), decimal digits (0-9), hyphens (-), underscores (_), periods (.), and tildes (~) are unreserved characters. They hold no structural URI meaning and never require percent-encoding.
Yes. Clean, readable URLs help search engine bots crawl sites accurately. When query parameters contain unescaped spaces, non-ASCII letters, or broken query delimiters, search bots may encounter 400 or 404 response codes. Proper percent-encoding prevents crawler misinterpretation and indexation errors.
Our URL Encoder and Decoder operates 100% on the client side using your browser's local JavaScript engine. Your inputs, query values, and decoded text never travel to external servers or remote databases, keeping private tokens and parameters safe.
When an ampersand or equal sign is part of a parameter value rather than a parameter separator, encode it using encodeURIComponent(). An ampersand encodes as %26 and an equal sign encodes as %3D. This prevents web servers from splitting your single value into separate, unintended query pairs.
Similar Tools
Base64 Encode & Decode
UUID Generator & Decoder
Website Redirect Checker
Disclaimer
The URL Encoder/Decoder tool is provided for educational and developer convenience. All conversion logic runs entirely in your local browser. Do not transmit sensitive passwords or unencrypted private keys through unverified network channels.