URL Encoder and Decoder

What is URL percent-encoding

Every URL is constrained to a limited set of printable ASCII characters. Characters outside that set, including spaces, non-ASCII letters, and many punctuation marks, cannot appear directly in a URL without causing ambiguity or transmission errors. Percent-encoding solves this by replacing each unsafe byte with a percent sign followed by two uppercase hexadecimal digits. A space becomes %20, a hash becomes %23, an at-sign becomes %40, and a non-ASCII character like the accented letter é becomes the multi-byte sequence %C3%A9.¹

The specification is defined in RFC 3986. It separates characters into three categories. Unreserved characters (letters, digits, hyphens, dots, underscores, and tildes) are safe to use as-is anywhere in a URL. Reserved characters (such as /, ?, #, &, and =) have structural meaning and must be percent-encoded when they appear as data values rather than structural delimiters. All other characters must always be percent-encoded.²

Why percent-encoded strings show up everywhere

Browser DevTools, server logs, and API responses frequently display percent-encoded strings. Knowing how to read and reverse them is a practical skill for debugging HTTP requests, constructing URLs programmatically, and understanding what a link is actually requesting before you follow it. Spotting the difference between a literal ampersand and an encoded %26, for example, can explain why a URL behaves differently than it looks in a log line.

encodeURIComponent vs encodeURI

JavaScript exposes two built-in functions for URL encoding, and choosing the wrong one is a common source of bugs because each function leaves a different set of characters untouched. Picking the wrong function can corrupt a query string or leave unsafe characters in a URL, which is why understanding the difference between them matters before you encode anything.

When to use encodeURI

encodeURI is designed for complete URLs. It preserves all characters that have structural meaning in a URL: the protocol colon and slashes, question marks, hash signs, ampersands, equals signs, and domain punctuation. Passing a full URL like https://example.com/search?q=hello world through encodeURI safely encodes the space as %20 while leaving the protocol, domain, path separators, and query string structure intact.³ Because encodeURI leaves the equal sign and ampersand untouched, it is the wrong choice for encoding a single value that will later be inserted into a query string.

encodeURIComponent is designed for individual URL components such as a query parameter value, a path segment, or a hash fragment. It encodes everything except letters, digits, and the four characters -_.~. This makes it safe to embed as a value inside a query string, since it will encode the & and = characters that would otherwise break the query string structure. Passing hello world through encodeURIComponent gives hello%20world, which is safe to append as ?q=hello%20world.⁴

The practical rule: use encodeURIComponent when building URLs from parts by encoding each value. Use encodeURI only when you already have a complete URL and need to make it safe for an HTML attribute like href. Never use encodeURI on user-supplied query parameter values or you will produce a URL that cannot be reliably decoded.

Form encoding and the + character

The application/x-www-form-urlencoded format is the default encoding for HTML form submissions. It is nearly identical to standard percent-encoding but uses a plus sign (+) rather than %20 to represent spaces. This convention traces back to early web forms and remains common today in GET request query strings generated by HTML forms.¹

When a browser submits a form, the request body or appended query string uses this format. Many server-side frameworks and web APIs decode + back to a space automatically when parsing form data. However, calling decodeURIComponent directly on a form-encoded string will not convert plus signs to spaces. If you see unexpected + characters after decoding, the input was form-encoded. Replace each + with %20 before passing it to decodeURIComponent, or use a dedicated form parser.

Choosing the right decoder for the format you have

Before decoding, identify which format the source string uses. A query string pulled from an HTML form submission likely uses the plus-for-space convention, so it needs the + to %20 replacement step before decodeURIComponent. A path segment or a value encoded by JavaScript code is more likely to be standard percent-encoding. The tool handles both cases for you, which is why the decode output often matches the original value even when the plus-sign conversion is subtle.⁵

Parsing and editing query strings

Query strings follow a consistent structure: key-value pairs separated by &, with keys and values joined by =. The query string begins after the ? in a URL. A URL like https://example.com/search?q=cats&page=2&sort=date contains three parameters: q, page, and sort.² The same structure appears in OAuth redirects, analytics tracking links, and API endpoints, so being able to read and modify query strings by hand is a useful debugging skill.

Editing values without breaking the structure

When you paste a URL with a query string in decode mode, this tool parses the parameters and shows them in an editable table. Each row displays the decoded key and an editable field for the decoded value. Changing a value immediately rebuilds the full encoded query string shown below the table. This makes it straightforward to debug API calls, construct test requests, or understand what a URL is requesting without manually working through percent-encoded characters.

The rebuilt query string uses encodeURIComponent on every key and value, so the output is safe to append directly to any URL. The original input field is not overwritten when you edit the table, which prevents re-parse loops and lets you compare the original and modified strings side by side.