Encode text or a full URL into a safe percent-encoded format, or decode a percent-encoded URL back into readable text.
📂 Technology & InternetFill in the fields on the left, then press the button to see your result instantly. Everything runs locally in your browser — no sign-up required, and no data is ever sent anywhere.
URL encoding (also known as percent-encoding) converts characters that aren't safe in a URL (such as spaces, non-Latin characters, or special symbols like &, ?, and #) into a format starting with a percent sign (%) followed by its hexadecimal value, ensuring the URL works correctly across all browsers and servers without conflicting with the characters reserved in the URL's own structure. This tool converts any text or link into its safely encoded form (encoding), or converts any encoded link back into its original, readable text form (decoding) — useful when building API URLs, passing query parameters, or analyzing complex links. Reserved characters like & and = need encoding specifically because the URL format itself uses them as structural separators between different parameters, so leaving them unencoded inside an actual data value would make the URL impossible to parse correctly. Decoding reverses the process cleanly, turning a long, heavily percent-encoded link copied from a browser address bar or an analytics report back into plain, readable text for quick inspection.
A URL is not simply free-form text — it follows a strict structural format where specific characters carry special, reserved meaning: a question mark separates the base address from its query parameters, an ampersand separates one parameter from the next, and an equals sign separates a parameter's name from its value. This structure is exactly what makes URLs parseable by browsers and servers, but it also creates a real problem whenever the actual data being transmitted needs to include one of these reserved characters as ordinary content rather than structure.
Percent-encoding solves this by representing any character that cannot appear safely and unambiguously in a URL with a percent sign followed by that character's hexadecimal byte value. A space becomes %20, an ampersand within a data value becomes %26, and non-Latin characters (Arabic, Chinese, emoji, and so on) are encoded using their underlying UTF-8 byte representation, each byte written as its own percent-encoded hexadecimal pair.
Search engines and websites rely on this constantly and mostly invisibly to end users: searching for a multi-word phrase produces a URL with the spaces converted to %20 (or sometimes a plus sign, a related but slightly different convention used specifically within query strings), and searching in a non-Latin script produces a URL filled with percent-encoded UTF-8 bytes, even though the search box itself displayed the query in ordinary, readable text.
Building URLs programmatically — constructing an API request with a search term, a filter value, or a redirect destination as a parameter — requires percent-encoding any user-provided or dynamic content before inserting it into the URL, since failing to do so risks the entire URL being misinterpreted if that content happens to contain any character with structural meaning to the URL format itself, such as an ampersand or an equals sign appearing unexpectedly inside a data value.
Decoding works in reverse, converting a URL's percent-encoded sequences back into their original, human-readable characters — genuinely useful for inspecting a long, heavily encoded link (common in analytics tracking URLs, redirect chains, or complex API requests) to understand exactly what data it actually contains, without needing to manually decode each percent sequence by hand.
URL encoding only replaces unsafe or reserved characters (spaces, &, ?, non-Latin letters) with a %-prefixed code so a string can safely sit inside a URL, while Base64 re-encodes entire data into a completely different alphabet — they solve different problems.
A space isn't a valid character inside a URL, so it must be percent-encoded as %20 (the standard form used by encodeURIComponent) — some older systems use + instead, but %20 is the more broadly compatible form.
You can, but it's usually more reliable to encode only the individual parameter values (like a search term) rather than the whole URL, since encoding the slashes and colons in https:// would break the URL structure itself.