What is the difference between encodeURI and encodeURIComponent?

encodeURI() encodes a full URL but leaves characters like :, /, ?, #, and & untouched because they have structural meaning in a URL. encodeURIComponent() encodes everything except unreserved characters (letters, digits, -, _, ., ~). This tool uses encodeURIComponent() by default because it is the correct choice for encoding individual parameter values. If you need to encode a full URL while preserving its structure, use the \\\"Encode full URI\\\" mode.

Is my data sent to a server?

No. The encoding and decoding happen entirely in your browser using JavaScript's built-in URL encoding functions. You can verify this by opening your browser's DevTools Network tab: no outbound requests are made when you encode or decode. This matters when you are working with API keys, tokens, or internal URLs that should not be shared.

What is double encoding and how do I fix it?

Double encoding happens when an already-encoded string gets encoded again. For example, %20 (a space) becomes %2520 because the % sign itself gets encoded to %25. This usually happens when a framework or library auto-encodes a value that you already encoded manually. To fix it, paste the string into the decoder and decode it twice. If the second decode produces the same result as the first, the string was only single-encoded.

What characters are safe to leave unencoded in a URL?

Per RFC 3986, unreserved characters are: uppercase and lowercase letters (A-Z, a-z), digits (0-9), hyphen (-), period (.), underscore (_), and tilde (~). These never need encoding. Reserved characters like :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, and = have special meaning in URLs and must be encoded when used as data rather than delimiters.

Why does my URL break when I include a plus sign?

In the application/x-www-form-urlencoded format used by HTML forms, a + sign represents a space. So if your actual data contains a literal +, it must be encoded as %2B to avoid being interpreted as a space on the server side. This tool encodes + to %2B by default, which is the correct behavior for parameter values.

Does this tool support batch encoding of multiple values?

The current version handles one input string at a time. For batch encoding, paste each value on a separate line and the tool will encode each line individually, preserving the line breaks in the output. This is useful when you have a list of parameter values to encode for a bulk API call.

URL Encoder / Decoder

This tool encodes and decodes URLs entirely in your browser. Paste a raw string and get a percent-encoded URL, or paste an encoded URL and get back the readable original. No data leaves your device. The tool handles query parameters, path segments, Unicode characters, and reserved characters per RFC 3986. It is free, requires no login, and works offline once the page loads.

Mode

ScopeEncoding standard

Input

Encoding rules differ by context. Use query mode for parameter values and full URL mode when the whole link must stay valid.

Result

(empty)

Common encodings

Character	RFC 3986	Form
(space)	%20	+
&	%26	%26
=	%3D	%3D
?	%3F	%3F
#	%23	%23
/	%2F	%2F
你好	%E4%BD%A0%E5%A5%BD	%E4%BD%A0%E5%A5%BD

How this tool works

The URL encoder converts characters that are not permitted in URL components into their percent-encoded equivalents, expressed as %XX hex pairs. It also decodes percent-encoded strings back to plain text. RFC 3986 defines different encoding rules for each component of a URL: path segments, query parameter values, and fragments each have their own set of allowed characters. Query parameter values must encode spaces, ampersands, equals signs, and most punctuation. Path segments leave forward slashes unencoded but encode spaces and most other special characters. The tool applies the correct rule set based on which component type you select. Encoding happens entirely in your browser using JavaScript built-in functions. No text you enter is sent to any server. You can confirm this by opening your browser developer tools and watching the Network tab while you type.

When to use URL encoding

URL encoding is required any time you pass user-generated text, search queries, file names, or parameter values through a URL. Web servers and APIs reject or misinterpret requests that contain unencoded special characters. A search query containing & breaks the parameter boundary, so the server reads the characters after the ampersand as a new parameter instead of part of the value. A path containing a space becomes an invalid URL in most browsers, which may strip the space or refuse to navigate. You need URL encoding when building redirect targets dynamically, when generating share links for social media, when constructing OAuth authorization URLs, when passing callback URLs as query parameters, and when embedding API keys or tokens in URLs. Front-end frameworks like React and Vue automatically encode values you pass to their link components, but raw string concatenation in JavaScript or server-side code does not. Encoding manually before concatenation prevents broken links and injection risks.

RFC 3986 vs form encoding

The tool supports two encoding conventions that differ in how they handle the space character and a handful of symbols. RFC 3986 percent-encoding converts every character that is not an unreserved character (letters, digits, hyphen, period, underscore, tilde) into its %XX hex representation. A space becomes %20. This is the standard used by modern HTTP libraries, the Fetch API, and URL parsers in all current browsers. Form encoding, also called application/x-www-form-urlencoded, follows the older HTML form specification. In that convention, a space encodes as a plus sign instead of %20, and the plus sign itself must be encoded as %2B to distinguish it from a space. Form encoding appears in HTML form submissions and in many older APIs that expect form-style POST bodies. When you decode an incoming string, the tool checks whether it contains plus signs that represent spaces and lets you choose which interpretation to apply. Choosing the wrong decode mode produces garbled output with literal plus signs in the middle of values.

Unicode and international characters

URL encoding handles Unicode by first converting each character to its UTF-8 byte sequence, then percent-encoding each byte separately. The emoji thumbs-up character (U+1F44D) encodes to four bytes: F0, 9F, 91, 8D. In a URL, it appears as %F0%9F%91%8D. Latin-script characters with diacritics are typically two-byte UTF-8 sequences. The French word été encodes as %C3%A9t%C3%A9, where %C3%A9 is the UTF-8 percent-encoding of the e-acute character. Browsers and modern HTTP clients handle UTF-8 encoding automatically when you type a URL or use the Fetch API with a URL object. Problems appear when legacy systems or hand-constructed strings use a different encoding, such as ISO-8859-1, or when a developer encodes only part of a string and leaves the rest raw. The tool always decodes percent-encoded sequences as UTF-8, which is the standard. If you are working with a system that sends Latin-1 encoded URLs, the decoded output may contain the wrong characters for bytes above 0x7F.

Common encoding mistakes

Double encoding is the most common URL encoding error. It occurs when an already-encoded string is encoded again. The sequence %20, which represents a space, contains a percent sign. Encoding it a second time turns the percent sign into %25, producing %2520, which decodes back to the literal characters %20 rather than a space. Double encoding usually happens when middleware or a framework encodes a value that your code already encoded. To diagnose it, paste the suspect string into the decoder and decode it once. If the result still contains percent sequences where you expected plain text, decode it again. If the second decode gives you clean text, the original value was double-encoded. The fix is to remove one of the encoding steps in the code path. A second common mistake is encoding the wrong component type. Encoding a full URL with encodeURIComponent encodes the colon, forward slashes, and question mark, destroying the URL structure. Use encodeURIComponent only on individual parameter values. Use the full URI mode when you need to encode a URL while keeping structural characters intact.

Worked example

Query value "sale price & discount=10%" under RFC 3986 becomes sale%20price%20%26%20discount%3D10%25. The space encodes to %20, the ampersand to %26, the equals sign to %3D, and the percent sign to %25. Under form encoding the spaces become plus signs: sale+price+%26+discount%3D10%25. Decoding the Japanese characters %E6%97%A5%E6%9C%AC%E8%AA%9E returns the UTF-8 sequence for the word meaning "Japanese language." The emoji U+1F44D thumbs-up encodes as %F0%9F%91%8D across four bytes.

Related tools

Frequently asked questions

What is the difference between encodeURI and encodeURIComponent?
encodeURI() encodes a full URL but leaves characters like :, /, ?, #, and & untouched because they have structural meaning in a URL. encodeURIComponent() encodes everything except unreserved characters (letters, digits, -, _, ., ~). This tool uses encodeURIComponent() by default because it is the correct choice for encoding individual parameter values. If you need to encode a full URL while preserving its structure, use the \\\"Encode full URI\\\" mode.
Is my data sent to a server?
No. The encoding and decoding happen entirely in your browser using JavaScript's built-in URL encoding functions. You can verify this by opening your browser's DevTools Network tab: no outbound requests are made when you encode or decode. This matters when you are working with API keys, tokens, or internal URLs that should not be shared.
What is double encoding and how do I fix it?
Double encoding happens when an already-encoded string gets encoded again. For example, %20 (a space) becomes %2520 because the % sign itself gets encoded to %25. This usually happens when a framework or library auto-encodes a value that you already encoded manually. To fix it, paste the string into the decoder and decode it twice. If the second decode produces the same result as the first, the string was only single-encoded.
What characters are safe to leave unencoded in a URL?
Per RFC 3986, unreserved characters are: uppercase and lowercase letters (A-Z, a-z), digits (0-9), hyphen (-), period (.), underscore (_), and tilde (~). These never need encoding. Reserved characters like :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, and = have special meaning in URLs and must be encoded when used as data rather than delimiters.
Why does my URL break when I include a plus sign?
In the application/x-www-form-urlencoded format used by HTML forms, a + sign represents a space. So if your actual data contains a literal +, it must be encoded as %2B to avoid being interpreted as a space on the server side. This tool encodes + to %2B by default, which is the correct behavior for parameter values.
Does this tool support batch encoding of multiple values?
The current version handles one input string at a time. For batch encoding, paste each value on a separate line and the tool will encode each line individually, preserving the line breaks in the output. This is useful when you have a list of parameter values to encode for a bulk API call.