BrowserTools
Advertisement
Home / Encoders / URL Encode / Decode

URL Encode / Decode

Percent-encode or decode URLs and query parameters — component-safe and full-URI modes.

Loading URL Encode / Decode… If nothing happens, please enable JavaScript.

Frequently asked questions

Is my data uploaded to a server?
No. Encoding and decoding happen entirely in your browser using JavaScript's built-in encodeURIComponent, decodeURIComponent, encodeURI, and decodeURI functions. Your input never leaves your device and no network request is made.
What characters are considered 'safe' and left unencoded?
RFC 3986 defines the unreserved characters — A–Z, a–z, 0–9, hyphen (-), underscore (_), period (.), and tilde (~) — as always safe and never encoded. In full-URI mode, the reserved structural characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) are also preserved because they carry syntactic meaning in a complete URL.
What is the difference between the two modes?
Component mode (encodeURIComponent) is designed for encoding individual query parameter values or path segments. It escapes everything except the unreserved characters, so an ampersand in a value becomes %26 and will not be confused with a parameter separator. Full-URI mode (encodeURI) is designed for complete URLs: it preserves the reserved structural characters so the URL remains valid and parseable after encoding.
Why does a space sometimes become + and sometimes %20?
It depends on the context. The application/x-www-form-urlencoded format — used by HTML forms — encodes spaces as + for historical reasons. Strict percent-encoding as defined by RFC 3986 uses %20 for spaces everywhere else, including in path segments and modern query strings. When in doubt, %20 is the safe choice; + should only be decoded as a space inside a form body, not in a URL path.
Are there characters that can never appear in a URL even when encoded?
All bytes 0x00–0xFF can be represented in a URL via percent-encoding, so technically any sequence of bytes is expressible. However, practical limits exist: very long URLs (over 2,000 characters) may be rejected by browsers, servers, or proxies. International domain names (IDNs) use Punycode rather than percent-encoding for the host portion of a URL.
Does this tool handle Unicode and emoji correctly?
Yes. JavaScript's encodeURIComponent converts characters to their UTF-8 byte sequence before percent-encoding each byte, which is the correct behaviour per RFC 3986. For example, the euro sign € (U+20AC) becomes %E2%82%AC — the three bytes of its UTF-8 encoding. Emoji and any other Unicode codepoint are handled the same way.
Can I use this to decode a URL that was double-encoded?
You can apply decoding multiple times by pasting the output back as input. Double-encoding happens when an already-encoded string is encoded again, turning %20 into %2520 (the % itself becomes %25). If you see literal %25 sequences in a decoded URL, the original value was double-encoded and you need to decode it a second time.
Is URL encoding the same as HTML entity encoding?
No. They are separate systems. URL encoding uses percent-encoding (%20, %26, etc.) to make characters safe inside URIs. HTML entity encoding uses named or numeric references (&,  , etc.) to escape characters that have special meaning in HTML markup. They are sometimes confused because both convert & — to %26 in a URL and to & in HTML — but they should never be mixed.
What is the difference between a URI and a URL?
A URI (Uniform Resource Identifier) is the broader concept: a string that identifies a resource by name, location, or both. A URL (Uniform Resource Locator) is a specific kind of URI that provides the means to locate the resource — it includes a scheme (https://), a host, and a path. In everyday web development the terms are used interchangeably, but technically every URL is a URI, while not every URI is a URL.
Why does encoding an already-encoded string produce garbled output?
Because the percent sign (%) is itself encoded as %25, encoding an encoded string turns every %XX sequence into %25XX. For example, %20 becomes %2520. Always decode first if you are unsure whether the input is already encoded, rather than encoding it again. This tool's decode mode will restore the original string from a single level of encoding.

About URL Encode / Decode

Percent-encoding, commonly called URL encoding, is the mechanism defined in RFC 3986 for safely representing arbitrary characters inside a Uniform Resource Identifier. The internet's addressing system was designed around ASCII, so any character outside a small safe set — spaces, accented letters, punctuation, emoji, or raw binary — must be replaced by a percent sign followed by two hexadecimal digits representing the character's byte value in UTF-8. The scheme has been part of the web since Tim Berners-Lee defined URLs at CERN in 1990 and was formally standardised in RFC 1738, later superseded by RFC 3986 in 2005.

URL encoding is unavoidable whenever you build or parse web addresses programmatically. Query string values that contain spaces, ampersands, or equal signs would break parameter parsing if left unencoded. Form submissions default to application/x-www-form-urlencoded, which percent-encodes everything and converts spaces to +. REST API clients must encode path segments that contain slashes or question marks so the server does not interpret them as structural characters. Webhook payloads, OAuth redirect URIs, and deeplinks all rely on careful encoding and decoding to pass data without ambiguity.

This tool handles percent-encoding and decoding entirely in your browser. It offers two modes to match the two standard JavaScript functions. Component mode (equivalent to encodeURIComponent) is intended for individual values — a search term, a filename, an OAuth parameter — and escapes everything except the unreserved characters A–Z, a–z, 0–9, hyphen, underscore, period, and tilde. Full-URI mode (equivalent to encodeURI) preserves the structural characters of a complete URL — colon, slash, question mark, hash, ampersand, equals — and is useful when you want to normalise a URL without breaking its structure. Because everything runs locally, no input is ever sent to a server.

A common mistake is to encode an entire URL with encodeURIComponent: this escapes the colons and slashes, producing a broken address. Use component mode only on individual values before assembling them into a URL. Conversely, forgetting to encode values that contain & or = inside query strings leads to parameters being silently split or merged on the receiving end. Also note that the + character means a space only inside application/x-www-form-urlencoded bodies; in path segments, a literal + should be percent-encoded as %2B.

How percent-encoding got its name

Percent-encoding takes its name from the literal percent sign (%) used as its escape character. When Tim Berners-Lee defined the URL syntax at CERN in 1990, he needed a way to represent arbitrary bytes that would be unambiguous in ASCII text. He chose % because it was printable, rarely used in identifiers, and visually distinct — making encoded sequences easy to spot at a glance.

The original URL specification (RFC 1738, 1994) already required percent-encoding for unsafe characters, but different systems disagreed on which characters were 'unsafe' and how to handle Unicode. It took until 2005 — and RFC 3986 — for a definitive standard to emerge, along with a companion document (RFC 3987) defining IRIs (Internationalized Resource Identifiers), which allow Unicode characters directly in the syntax.

Today, virtually every programming language ships a URL-encoding function in its standard library, yet subtle differences remain: PHP's urlencode() encodes spaces as +, Python's urllib.parse.quote() uses %20, and JavaScript's encodeURIComponent() follows RFC 3986. This diversity is why cross-language API integrations sometimes struggle with encoding mismatches — the same character can look completely different depending on which library serialised it.

Advertisement