URL Encoder & Decoder Online

Encode or decode URLs and query strings using percent-encoding. Choose between full URL encoding and component encoding to handle special characters correctly. All processing runs locally in your browser with zero server communication.

Encoding mode:
Characters: 0 Bytes (UTF-8): 0
Encoded output will appear here...
Characters: 0 Increase:

Core Capabilities

Real-Time Encoding

Convert text and URLs to their percent-encoded form instantly as you type. The tool uses the browser's native encodeURI and encodeURIComponent functions for accurate and standards-compliant encoding. There is no server round-trip, no upload delay, and no character limit. Results appear immediately in the output panel, making it easy to iterate on complex query strings or multi-parameter URLs. The real-time feedback loop helps you understand exactly which characters are being encoded and why, which is especially valuable when debugging URL construction issues in web applications.

Dual Encoding Modes

Choose between two encoding strategies depending on your use case. The encodeURIComponent mode encodes every special character including slashes, colons, and question marks, making it ideal for encoding individual query parameter values, path segments, or any string that will be embedded inside a larger URL. The encodeURI mode preserves URL structural characters like the protocol separator, path delimiters, and query string markers, making it suitable for encoding a complete URL while keeping its structure intact. Switching between modes is instant and the output updates automatically.

Complete Privacy

Your data never leaves your device. Every encoding and decoding operation is executed entirely on the client side, inside your web browser's JavaScript engine. No information is transmitted to any server, stored in any database, or logged anywhere. This makes the tool safe for encoding sensitive URLs that contain API keys, authentication tokens, session identifiers, or private query parameters. You can verify this by inspecting your browser's network tab while using the tool. The page works fully offline after initial load because it does not depend on any server-side component for its core functionality.

Getting Started with URL Encoder/Decoder

  1. Select your mode. Click the Encode tab to convert text into a percent-encoded URL string, or click the Decode tab to convert an encoded string back into readable text. Choose between encodeURIComponent (encodes all special characters) and encodeURI (preserves URL structural characters) depending on whether you are encoding a query parameter value or a full URL.
  2. Enter your data. Type or paste your text, URL, or query string into the input textarea. The character and byte counts update in real time as you type. For encoding, enter the raw unencoded text. For decoding, paste the percent-encoded string you want to convert back to human-readable form.
  3. Process and copy. Click the Encode or Decode button to transform your data. The result appears instantly in the output panel along with character count statistics and the size increase ratio. Click Copy Output or the Copy button in the output panel to send the result to your clipboard for use in your code, API calls, or browser address bar.
Pro Tip

Spaces are encoded differently depending on context: use %20 in URL path segments and + in query string parameters (application/x-www-form-urlencoded). In JavaScript, encodeURIComponent() produces %20, while form submissions use +. Know which one your API expects.

Common Mistake

Double-encoding URLs that are already encoded. Encoding %20 again produces %2520, which the server interprets as a literal %20 string instead of a space. Always check if your input is already percent-encoded before running it through the encoder.

Common Scenarios

API Developer

Nina builds RESTful APIs that accept search queries with special characters in URL parameters. She encodes test strings here to verify her backend correctly decodes multi-byte Unicode characters, spaces, and ampersands in query values.

SEO Specialist

Tariq debugs crawl errors from Google Search Console caused by improperly encoded URLs. He decodes the error URLs to identify which characters broke the link, then provides the correctly encoded version to the development team.

QA Engineer

Hana tests web applications by injecting special characters into URL parameters. She encodes payloads containing quotes, angle brackets, and Unicode characters to verify the application handles edge cases without breaking or exposing vulnerabilities.

Common URL Encoded Characters

The following table lists frequently encountered characters and their percent-encoded representations. These encodings are defined by RFC 3986 and are used whenever a character cannot appear literally in a URL.

CharacterEncodedDescription
(space)%20Space character
!%21Exclamation mark
#%23Hash / fragment identifier
$%24Dollar sign
&%26Ampersand / query separator
'%27Apostrophe / single quote
(%28Opening parenthesis
)%29Closing parenthesis
+%2BPlus sign
,%2CComma
/%2FForward slash / path separator
:%3AColon
;%3BSemicolon
=%3DEquals sign
?%3FQuestion mark / query start
@%40At sign
[%5BOpening bracket
]%5DClosing bracket
{%7BOpening brace
}%7DClosing brace

Understanding URL Encoding and Percent-Encoding

URL encoding is a fundamental mechanism of the World Wide Web that ensures data can be safely transmitted within Uniform Resource Locators. Every URL is composed of a specific set of allowed characters defined by RFC 3986, the standard that governs URI syntax. When a URL needs to contain characters outside this permitted set, those characters must be converted into a special format known as percent-encoding. In percent-encoding, each unsafe character is replaced by a percent sign followed by two hexadecimal digits that represent the character's byte value in UTF-8 encoding. For instance, a space character becomes %20, an ampersand becomes %26, and an equals sign becomes %3D.

The need for URL encoding arises because URLs serve a dual purpose: they are both human-readable addresses and machine-parseable identifiers. Certain characters carry structural meaning within a URL. The colon and double slash separate the protocol from the host, the question mark marks the beginning of the query string, the ampersand separates key-value pairs in query parameters, and the hash sign introduces the fragment identifier. If these characters appear in the data portion of a URL without being encoded, they would be misinterpreted as structural delimiters, breaking the URL's intended meaning. URL encoding eliminates this ambiguity by converting data characters into an unambiguous percent-encoded representation.

RFC 3986 defines two categories of characters in URIs: unreserved characters and reserved characters. Unreserved characters include all uppercase and lowercase ASCII letters (A through Z, a through z), the ten digits (0 through 9), and four special symbols: the hyphen, period, underscore, and tilde. These characters can appear anywhere in a URL without encoding. Reserved characters include the colon, slash, question mark, hash, brackets, at sign, exclamation mark, dollar sign, ampersand, apostrophe, parentheses, asterisk, plus, comma, semicolon, and equals sign. These characters have special syntactic meaning and must be percent-encoded when they appear in a data context rather than a structural context.

JavaScript provides two built-in functions for URL encoding, and understanding the difference between them is essential for web developers. The encodeURIComponent function encodes all characters except unreserved characters as defined in RFC 3986. This makes it the correct choice for encoding individual components of a URL, such as query parameter values, path segments, and fragment identifiers. For example, if a search query contains an ampersand or an equals sign, using encodeURIComponent ensures those characters are percent-encoded and not mistaken for query string delimiters. The encodeURI function, on the other hand, is designed to encode a complete URI while preserving characters that form the structural skeleton of the URL, such as the protocol separator, path slashes, and query markers. Using encodeURI on a full URL keeps it structurally valid while encoding only the characters within each component that require it.

Non-ASCII characters, including accented letters, Chinese characters, Arabic script, emoji, and other Unicode code points, receive special treatment during URL encoding. These characters are first converted into their UTF-8 byte representation, and then each byte is individually percent-encoded. A single Unicode character can produce multiple percent-encoded triplets. For example, the Japanese character for mountain is represented as three bytes in UTF-8, resulting in three consecutive percent-encoded triplets in the URL. This multi-byte encoding ensures that URLs remain compatible with the ASCII-based infrastructure of the internet while supporting the full range of Unicode characters used in modern web content.

A common source of confusion is the difference between the space encodings %20 and +. The %20 format is the standard percent-encoding for a space as defined by RFC 3986 and is correct in all URL contexts. The plus sign as a space replacement is a convention from the application/x-www-form-urlencoded content type used by HTML forms. When a browser submits a form using the GET method, spaces in form field values are encoded as plus signs in the resulting query string. While most servers and URL parsers accept both formats in query strings, %20 is the universally safe choice for all parts of a URL. This tool uses the standard JavaScript encoding functions which produce %20 for spaces, ensuring maximum compatibility across all URL contexts.

URL encoding plays a critical role in web security as well. Improper encoding of user-supplied data in URLs can lead to injection attacks, broken links, and data corruption. Cross-site scripting attacks can exploit URLs that contain unencoded angle brackets or script tags. Open redirect vulnerabilities can arise when URL parameters contain unencoded redirect targets. SQL injection can occur through unencoded query parameters that reach a database layer. By consistently encoding all user-supplied values before inserting them into URLs, developers can prevent an entire class of security vulnerabilities. This tool helps developers verify their encoding logic by providing instant visual feedback on how special characters are transformed, making it easier to identify and fix encoding errors before they reach production systems.

Your Questions Answered

What is URL encoding?

URL encoding, also called percent-encoding, is a mechanism for converting characters into a format that can be safely transmitted within a Uniform Resource Locator. URLs are restricted to a specific set of ASCII characters defined by RFC 3986. Any character outside this allowed set must be represented using a percent sign followed by two hexadecimal digits corresponding to the character's byte value in UTF-8 encoding. For example, a space becomes %20, an ampersand becomes %26, and a question mark becomes %3F. This encoding ensures that special characters in data values are not confused with the structural delimiters that define the parts of a URL, such as the protocol, host, path, query string, and fragment.

What is the difference between encodeURI and encodeURIComponent?

These two JavaScript functions serve different purposes. encodeURI is designed to encode a complete URL while preserving characters that serve as structural delimiters: the colon and slashes in the protocol, the slashes in the path, the question mark before the query string, the ampersand between query parameters, and the hash before the fragment. It only encodes characters that are not valid anywhere in a URL. encodeURIComponent encodes all characters except the unreserved set (letters, digits, hyphen, underscore, period, and tilde), including the structural delimiters. Use encodeURIComponent when encoding individual values like query parameter values or path segments. Use encodeURI when you have a complete URL that already has the correct structure and you only need to encode characters within its components.

Why is a space encoded as %20 instead of a plus sign (+)?

The %20 encoding is the standard percent-encoding for a space character as defined by RFC 3986, and it is valid in all parts of a URL. The plus sign as a space substitute comes from the application/x-www-form-urlencoded format, which is used when HTML forms are submitted via the GET or POST method. In this form encoding format, spaces are replaced with plus signs to produce shorter query strings. While most web servers and URL parsers treat both %20 and + as spaces when they appear in a query string, the plus sign is not a valid space representation in other parts of a URL such as the path or fragment. For this reason, %20 is the universally safe and recommended encoding for spaces in URLs.

Which characters must be URL-encoded?

According to RFC 3986, characters outside the unreserved set should be percent-encoded when they appear in the data portions of a URL. The unreserved characters are the 26 uppercase ASCII letters (A-Z), the 26 lowercase ASCII letters (a-z), the 10 digits (0-9), and four symbols: hyphen (-), period (.), underscore (_), and tilde (~). All other characters, including spaces, reserved characters like & = ? / # : @ ! $ ' ( ) * + , ;, and all non-ASCII characters such as accented letters, Chinese characters, or emoji, must be percent-encoded. Reserved characters can appear unencoded only when they serve their designated structural role in the URL syntax.

Is URL encoding the same as HTML encoding?

No, URL encoding and HTML encoding are completely different mechanisms that serve different purposes. URL encoding (percent-encoding) converts characters into a %XX hexadecimal format for safe transmission within URLs. HTML encoding converts characters into HTML entity references such as & for ampersand, < for less-than, and > for greater-than to prevent them from being interpreted as HTML markup. Applying the wrong type of encoding leads to broken output. Using HTML encoding in a URL produces invalid percent sequences, and using URL encoding in HTML does not protect against markup injection. Each encoding must be applied in its correct context.

How does URL encoding handle Unicode characters?

Non-ASCII Unicode characters undergo a two-step encoding process. First, the character is converted to its UTF-8 byte representation, which may consist of one to four bytes depending on the code point. Then each byte is individually percent-encoded by prefixing it with a percent sign and expressing its value as two hexadecimal digits. For example, the copyright symbol has the UTF-8 byte sequence C2 A9, so it is encoded as %C2%A9. A Chinese character that requires three bytes in UTF-8 produces three percent-encoded triplets. Emoji and other characters from supplementary Unicode planes require four UTF-8 bytes and therefore produce four percent-encoded triplets. This multi-byte approach ensures that URLs remain composed entirely of ASCII characters while faithfully representing the full range of Unicode text.

Is my data safe when using this URL encoder?

Yes, your data is completely safe. This URL encoder and decoder runs entirely in your web browser using native JavaScript functions. All processing happens locally on your device, and no data is ever sent to any external server. Your input text, URLs, and encoded output are not stored, logged, or transmitted over any network. This makes the tool safe for encoding sensitive information such as API keys, authentication tokens, session identifiers, private URLs, and confidential query parameters. Unlike online tools that send your data to a server for processing, this implementation is genuinely client-side. You can verify this by disconnecting from the internet after loading the page and confirming that the tool continues to function normally.

URL Encoding Rules (RFC 3986)

URL encoding (also called percent-encoding) replaces unsafe characters with a percent sign followed by two hexadecimal digits representing the character's byte value. RFC 3986 defines exactly which characters are safe to use in URLs and which must be encoded.

Unreserved Characters (Never Encode)
A-Z a-z 0-9 - _ . ~

These 66 characters can appear anywhere in a URL without encoding. They are guaranteed safe across all URL components (scheme, host, path, query, fragment).

Reserved Characters (Context-Dependent)
: / ? # [ ] @ ! $ & ' ( ) * + , ; =

These 18 characters have special meaning in URLs. Encode them when used as data (in query values), but leave them unencoded when used for their reserved purpose (e.g., / as path separator).

Character Encoded Common Encounter
Space%20 or +Search queries, file names
&%26Query parameter separator
=%3DKey-value pair separator
#%23Fragment identifier, hex colors
%%25Percent sign in values
/%2FSlashes within query values

encodeURI vs encodeURIComponent: In JavaScript, encodeURI() encodes a full URL and preserves reserved characters like :, /, ?, and #. Use encodeURIComponent() for individual query parameter values where those characters must be encoded. Mixing these up is one of the most common URL encoding bugs.

Explore More Tools

URL Encoding Reference for Special Characters

CharacterEncodedUsage Context
Space%20 or +Query parameters, form data
!%21Required in some API parameters
#%23Fragment identifiers, hex colors in URLs
$%24Currency values in parameters
&%26Separating query parameters
+%2BMath expressions, phone numbers
/%2FPath segments when literal slash needed
=%3DSeparating key-value pairs
?%3FStart of query string when literal needed
@%40Email addresses in URLs
%%25The percent sign itself (must be escaped)

Learn More