URL Encoder / Decoder

A URL encoder converts text into a format that's safe to use inside a web address or a query string, replacing characters URLs can't contain literally with a percent sign followed by a two-digit hex code — %20 for a space, %26 for an ampersand, and so on. This tool runs that conversion, and its reverse, instantly in the browser: paste text or a URL, click Encode or Decode, and copy the result.

URLs are restricted to a specific, limited character set defined by the web standard that governs them, and anything outside that set — spaces, accented letters, symbols like & and =, or a raw non-ASCII character — has to be percent-encoded before it can safely travel inside a link, a query parameter, or an API request. Skipping this step is a common source of broken links, truncated form submissions, and API requests that silently drop part of their data at the first special character.

Percent-encoding, defined by the web standard RFC 3986, replaces an unsafe character with a % followed by that character's two-digit hexadecimal ASCII value: a space becomes %20, an ampersand becomes %26, an equals sign becomes %3D, and a forward slash becomes %2F. RFC 3986 calls out a specific set of "unreserved" characters that never need encoding: uppercase and lowercase letters, digits, and four symbols — hyphen, period, underscore, and tilde. Everything else is a candidate for encoding depending on where it appears in the URL.

Reserved characters like &, =, ?, #, and / have special meaning in URL syntax — & separates query parameters, = separates a parameter's name from its value, and # marks a fragment — so if one of those characters needs to appear as literal data rather than as a URL delimiter, it must be percent-encoded, or it will be misread as part of the URL's structure instead of as content.

• Unreserved (never encoded): A-Z, a-z, 0-9, hyphen, period, underscore, tilde
• Reserved (structural, encode when used as literal data): & = ? # / : @
• Space becomes %20 with encodeURIComponent
• Non-ASCII characters (accented letters, emoji) are always percent-encoded, often as multiple %XX bytes

JavaScript provides two different built-in functions for this, and mixing them up is a frequent source of broken URLs. encodeURI is meant for encoding a complete, already-structured URL — it leaves reserved characters like /, :, ?, &, and # alone since those are assumed to be legitimate parts of the URL's structure, and it only encodes characters that shouldn't appear in a URL at all, like spaces.

encodeURIComponent is meant for encoding a single piece of data that will be inserted into a URL, such as one query parameter's value — it encodes reserved characters too, since a raw & or = inside a value would otherwise be misread as a delimiter rather than as part of the data. This tool's Encode and Decode buttons always use encodeURIComponent and decodeURIComponent, which is the correct and more commonly needed choice for encoding a value like a search term or form field rather than a full link; there's no separate encodeURI mode here for encoding an entire pre-built URL while leaving its slashes and colons untouched.

A literal space is not allowed in a URL at all, so it always needs to be represented some other way. The standard percent-encoded form is %20, and that's what this tool's encodeURIComponent-based Encode button produces. A different, older convention represents a space as a plus sign instead, but that convention applies specifically to the application/x-www-form-urlencoded format used by HTML form submissions, not to percent-encoding generally.

This distinction matters when working with an API or a form library, since %20 and + are not interchangeable everywhere: a server expecting form-encoded data may treat + as a literal plus sign rather than a space if it's not in the right encoding context. This tool always outputs %20 for spaces, matching standard percent-encoding rather than the form-specific + convention.

When building a URL with multiple query parameters, each parameter's name and value should be encoded individually with encodeURIComponent before being joined together with & and = characters, rather than encoding the entire query string as one block. Encoding the whole string at once would leave the & and = separators themselves unencoded, which is exactly what's needed for them to work as delimiters — but it also means any literal & or = inside a value passed through unencoded won't be escaped.

The safest pattern is: encode each value separately with this tool's Encode button, then assemble the full URL or request body by hand, joining the already-encoded pieces with the unencoded & and = separators. This avoids double-encoding a parameter that's already safe while making sure every literal special character inside a value is properly escaped.

Decoding reverses the process: every %XX sequence in the input is converted back to the character it represents, so %20 becomes a space and %26 becomes an ampersand again. This is useful for reading a long, encoded query string copied from a browser's address bar, a server log, or an API response, where the encoded form can be hard to read at a glance.

Decoding can fail if the input contains a malformed percent sequence, such as a % not followed by two valid hex digits, since that isn't a legal percent-encoded value; this tool reports a decoding error in that case rather than guessing at the intended character. Paste the encoded string exactly as received, without adding or removing any % characters by hand, to avoid triggering that error.