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.²

The é example from the opening paragraph generalizes. A URL is a byte stream, and percent-encoding escapes bytes, so a character whose UTF-8 encoding spans several bytes becomes several escapes: é takes two bytes and therefore two escapes, and an emoji takes four and therefore four.¹ One decode restores the character, because the escapes return the original bytes and those bytes are then read back together as UTF-8 text. Counting escapes is therefore a rough way to count bytes: four escapes in a row usually means one four-byte character, not four separate ones.

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.

Double encoding and the %25 pattern

Double encoding is the most common percent-encoding bug. A literal percent sign must itself be escaped as %25, so running an encoder over a string that was already encoded turns %20 into %2520 and %3D into %253D. The doubled artifact appears whenever two layers of a pipeline each encode, when a library encodes a value the caller already encoded, or when an encoded string is pasted into a field that encodes on save. The result is a URL that decodes to another encoded string instead of the value you meant to send, so the server receives a different value than the one you intended.

Spotting it here takes one decode pass. Decode a suspect string once: if the output still contains percent escapes, that is the tell, because the first pass only peeled the outer shell. Copy that output, paste it into the input, and decode again to recover the original. The code-side fix is to encode exactly once, at the boundary that builds the URL, and never to re-encode data that arrived already encoded. This tool performs one decode per interaction and never re-decodes automatically, which is what makes the two-step check reliable and repeatable.

Percent-Encoding URLs: When and How

Knowing how percent-encoding works is half the job; the other half is knowing which part of the URL you are encoding, because the path, the query string and the fragment each allow different characters. The guide below shows which characters to encode in each component, the encoding functions for each language and context, the mistakes that lead to double encoding and how fragments and mailto links differ from ordinary URLs.

// Wrong: encodeURI applied to a component value leaves & and = unencoded
const category = "food & drink";
const url = `/items?category=${encodeURI(category)}`;
// → /items?category=food%20&%20drink  (& breaks the query!)

// Correct: encodeURIComponent encodes & and = in values
const url2 = `/items?category=${encodeURIComponent(category)}`;
// → /items?category=food%20%26%20drink

# Wrong: value already encoded encoding again produces %25
from urllib.parse import quote
received = "hello%20world"  # came from a URL query param
encoded = quote(received, safe="")  # → "hello%2520world" (double-encoded!)

# Correct: decode first then re-encode for the new URL
from urllib.parse import unquote, quote
decoded = unquote(received)   # → "hello world"
re_encoded = quote(decoded, safe="")  # → "hello%20world"

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.

Percent-encoding beyond JavaScript

The standard is language-neutral. RFC 3986 defines which bytes need escaping and the %XX form every escape takes, so every mainstream language and HTTP client ships a percent-encoder and only the function names differ. When any of them escapes a character, the byte sequence it emits matches what the rows in this tool's encode panel produce for the same input. Differences between languages show up in which characters stay literal, not in what an escaped byte becomes. You can paste the same value here and read the three rows as the reference output.

The boundary is worth stating plainly. This tool speaks the two JavaScript functions shown above plus the form-encoding row. Other languages' full-string encoders may keep a slightly different set of characters literal, the way encodeURI keeps & and =, so when you port an encoded value between languages, compare outputs here rather than assuming the functions match one-to-one. A query string that survived one stack can arrive with broken separators in another for exactly this reason. The bytes never lie; the literal sets do. Encoding the value here after the transfer shows whether the structure survived intact.

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 each + changed to %20 before decodeURIComponent returns the intended spaces.⁵ A path segment or a value encoded by JavaScript code is more likely to be standard percent-encoding. Decoding here follows decodeURIComponent exactly, so a plus sign survives as a plus sign no matter which convention produced the string. When you cannot tell which convention a string uses, the ENCODE panel's form row is the comparison point: re-encoding the value shows exactly which characters each convention would produce.

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.

URL encoding is not HTML encoding

The two systems solve different parsers' problems. HTML escaping turns & into & and < into < so a value can sit inside markup without the markup parser reading it as tags; percent-encoding turns & into %26 so a value can sit inside a URL without the URL parser reading it as a separator. They protect different layers, and a value that travels through both layers needs each escape applied at its own layer. Neither escape substitutes for the other. Confusing the two produces a recognizable symptom, and the next paragraph names it.

The classic symptom is an & reaching a server inside a URL. That means HTML escaping leaked into a URL context, usually a template that escaped a value before building the query string. The correct order runs the other way: percent-encode the value when the URL is assembled, then HTML-escape the finished attribute when it lands in markup.⁶ Decoding a suspect string here helps you confirm which layer went wrong, because percent-decoding an already-HTML-escaped value leaves the entity intact and visible. The entity text surviving a percent-decode is the fingerprint of the markup layer.