URL Encode and Decode

URL encoding replaces unsafe characters in a URL with a percent sign followed by two hexadecimal digits. It is defined in RFC 3986 and is also called percent-encoding. Every reserved character, space, and non-ASCII byte gets replaced with a %XX sequence where XX is the uppercase hex representation of the byte value. For example, a space becomes %20, an ampersand becomes %26, and the Cyrillic letter "п" (UTF-8 bytes 0xD0 0xBF) becomes %D0%BF. This ensures URLs can be transmitted safely through HTTP, stored in log files, embedded in HTML, and parsed by browsers and servers without ambiguity.

Component encoding (JavaScript encodeURIComponent) encodes all special characters including /, ?, #, &, and = — use it for query parameter VALUES. Full URL encoding (encodeURI) preserves URL structure characters like / and ? and only encodes non-URL characters like spaces and Unicode — use it for complete URLs. Example: encodeURIComponent('foo/bar') produces foo%2Fbar (slash escaped), but encodeURI('https://x.com/foo/bar') produces https://x.com/foo/bar (slashes preserved). Use Component mode when the content will be embedded INSIDE a URL; use Full URL mode when the content IS a URL.

The + sign representing a space is a convention from HTML form encoding (MIME type application/x-www-form-urlencoded), NOT standard percent-encoding per RFC 3986. When browsers submit form data via GET or POST, they encode space as + instead of %20. This tool follows RFC 3986 strictly: + is a literal plus sign, and spaces are encoded as %20. If you are decoding form-data query strings (common in PHP $_GET), manually replace + with a space before feeding it to a URL decoder. JavaScript decodeURIComponent('a+b') returns 'a+b', not 'a b'.

You get double encoding. The percent sign itself (%) gets encoded to %25, so %20 (a space) becomes %2520 (a literal %20 as text). This is mathematically correct — the encoder cannot know whether your input is plain text containing a percent sign or already-encoded content. If you see %2520 in a URL, something encoded the URL twice by mistake. To avoid this, decode the string to plain text first, then encode only once. This tool does not auto-detect already-encoded input; it always encodes literally.

No. All URL encoding and decoding happens 100% in your browser using native JavaScript APIs (encodeURIComponent, decodeURIComponent, encodeURI, decodeURI). Your input text never leaves your device. The tool loads as a static HTML and JavaScript bundle from our server, but after that initial page load, all processing is client-side. There are no API calls, no telemetry of your input content, no server-side logging of what you encode. You can even use the tool offline after the first page load — the JavaScript is cached.

There is no hard limit. URL encoding and decoding are linear-time operations, so even very large inputs (megabytes of text) process instantly in your browser. The practical limit is your browser textarea rendering performance — typically fine up to ~10 MB of text. For bulk processing of millions of URLs, use command-line tools instead: Python's urllib.parse.quote in a script, or Node.js encodeURIComponent in a loop. This tool is optimized for interactive single-string encoding and debugging, not batch processing.

%20 is the percent-encoded form of a space character (ASCII code 32, hex 0x20). It is the RFC 3986 standard way to represent a space inside a URL — spaces cannot appear literally in URLs because space is a separator in the HTTP protocol. When you see %20 in a URL like https://example.com/search?q=hello%20world, the server decodes it back to "hello world". Form-encoded URLs (application/x-www-form-urlencoded) may use + instead of %20 for spaces, but standard URL percent-encoding always uses %20.

Per RFC 3986, only "unreserved characters" can appear literally in a URL: letters A-Z and a-z, digits 0-9, and the four marks -, _, ., ~. Every other character should be percent-encoded when used as data in a URL component. Reserved characters that have special meaning (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =) MUST be encoded when used as literal data in a query parameter value, but may appear unencoded when serving their structural role (e.g. / as a path separator). When in doubt, encode it.

Use encodeURIComponent() for query parameter values and encodeURI() for complete URLs. Example: encodeURIComponent('hello world&foo=bar') returns 'hello%20world%26foo%3Dbar'. To decode, use decodeURIComponent(). Both functions handle Unicode via UTF-8 encoding automatically — a Cyrillic or emoji character becomes multiple %XX bytes representing its UTF-8 encoding. For edge cases, the URLSearchParams API (new URLSearchParams({key: 'value'}).toString()) handles full URL construction correctly without manual encoding. Use encodeURIComponent for query values; use URLSearchParams for building query strings programmatically.

Use urllib.parse.quote() with safe='' to encode everything, or urllib.parse.quote_plus() to get form-style encoding (space → +). Example: from urllib.parse import quote; quote('hello world&foo=bar', safe='') returns 'hello%20world%26foo%3Dbar'. To decode, use urllib.parse.unquote() or urllib.parse.unquote_plus(). Python handles Unicode strings natively and UTF-8-encodes them before percent-encoding, matching JavaScript behavior. For building full URLs, use urllib.parse.urlencode({'q': 'hello world'}) which handles the form-encoding convention automatically.

The hex digits in percent sequences are case-insensitive for decoding — %2F and %2f both decode to /. However, RFC 3986 §6.2.2.1 specifies that uppercase letters are the canonical form, and implementations SHOULD use uppercase when percent-encoding. This matters for URL normalization and deduplication: %2F and %2f represent the same resource, but they are different byte sequences and may be treated as different URLs by cache keys or URL comparisons. This tool outputs uppercase hex in the canonical form.

Yes — they are two names for the same thing. "URL encoding" is the informal name used in tutorials and documentation; "percent encoding" is the formal name used in RFC 3986 and academic literature. The name "percent encoding" is more accurate because the encoding is not limited to URLs — it is also used for URIs, URNs, and any identifier that follows the RFC 3986 scheme:data syntax. "URL encoding" specifically refers to applying percent encoding to strings that will be placed inside a URL. Both terms refer to the %XX hex-digit substitution algorithm.

%2F is the percent-encoded form of / (forward slash). It appears in URL paths when software encodes a slash as literal data instead of a path separator. For example, if a filename contains /, encoding it as %2F prevents the browser from interpreting it as a directory boundary. Some web frameworks aggressively encode slashes in query parameters and path components for safety. However, RFC 3986 §3.3 notes that slashes in the path SHOULD remain unencoded when they serve as segment separators — so seeing %2F in a path segment usually means the content contains a literal slash character.

URL encoding for non-ASCII characters uses UTF-8 byte representation: the Unicode character is first encoded to its UTF-8 bytes (1-4 bytes), then each byte is percent-encoded. Example: Cyrillic "п" is UTF-8 0xD0 0xBF, so it encodes to %D0%BF. Chinese "中" is UTF-8 0xE4 0xB8 0xAD, so it encodes to %E4%B8%AD. All modern tools including JavaScript encodeURIComponent, Python urllib.parse.quote, and this tool handle this automatically. Avoid older Windows-1252 or Latin-1 encoding for URLs — they produce ambiguous output that modern browsers cannot decode.

Three different encodings for three different purposes. URL encoding (percent encoding) makes text safe for URLs — spaces become %20, reserved characters become %XX. HTML encoding (entity encoding) makes text safe inside HTML — < becomes &lt;, & becomes &amp; — so browsers do not interpret it as markup. Base64 encoding converts any binary data to a 65-character subset (A-Z, a-z, 0-9, +, /, =) safe for text transmission — it is NOT for URLs (though Base64URL with - and _ is a URL-safe variant). Use each for its intended purpose; do not mix them.