URL Encoder & Decoder

URL Encoder and Decoder: Percent-Encoding Made Simple

Paste any text above and click encode to replace unsafe characters with their percent-encoded equivalents (spaces become %20, ampersands become %26, non-ASCII characters become their UTF-8 byte sequences in %XX format). Paste a percent-encoded string and click decode to restore the original readable text. This url encoder and decoder handles standard percent-encoding (RFC 3986), the plus-sign space convention from HTML forms, and mixed input that contains both encoded and unencoded segments. Everything processes locally in your browser - no data is transmitted to any server.

Why URL Encoding Exists

URLs can only safely contain a restricted set of ASCII characters. Spaces, ampersands (&), question marks (?), hash signs (#), equals signs (=), and non-ASCII characters (accented letters, Chinese characters, emoji) all have reserved meanings in URL syntax or are prohibited by the URI specification. A space in a URL is ambiguous: does it end the URL or is it part of the path? An unencoded ampersand inside a query value gets interpreted as a parameter delimiter. URL encoding resolves these ambiguities by encoding every problematic character as a percent sign followed by two hexadecimal digits representing its byte value. The result is a URL that every server, browser, and intermediary proxy can parse unambiguously.

URL Encode and Decode in JavaScript

JavaScript provides two encoding functions with critically different scopes. encodeURI() encodes a full URL but preserves structural characters (: / ? # & = @) because they define the URL's architecture. Use it to encode the url as a whole when it contains non-ASCII characters or spaces but you want the structure to remain navigable. encodeURIComponent() encodes everything except unreserved characters (letters, digits, - _ . ~) and is designed for encoding individual query parameter values where structural characters like & and = must become data, not delimiters. Using encodeURIComponent on a full URL breaks it by encoding the colons and slashes. Using encodeURI on a parameter value fails to encode ampersands, creating phantom parameters. Choosing the wrong function is the most common url encoding bug in web applications.

URL Decode: Restoring Readable Text

When you encounter a URL like https://example.com/search?q=caf%C3%A9%20latte, the %C3%A9 is the UTF-8 encoding of é and %20 is a space. A url decoder reverses these sequences to show the original query: "café latte." The decode url operation is essential when debugging API requests from log files (where URLs are logged in encoded form), inspecting redirect chains (where each redirect may add another layer of encoding), and reading analytics reports that display encoded page paths instead of human-readable titles. Paste any encoded URL above and the tool restores every percent-encoded sequence to its original character, handling UTF-8 multi-byte sequences correctly for non-Latin scripts and emoji.

Double Encoding: The Most Common Bug

Double encoding occurs when an already-encoded string passes through another encoding layer. A space first becomes %20. Then the percent sign in %20 gets encoded to %25, producing %2520. The server receives %2520, decodes it once to %20, and displays a literal "%20" instead of a space. This typically happens when multiple software layers (frontend framework, HTTP client library, reverse proxy, API gateway) each apply encoding without checking whether the input is already encoded. The opposite problem - insufficient encoding - causes URLs to break silently when unencoded spaces terminate the URL prematurely or unencoded ampersands create unintended parameter splits. If a URL works in a browser address bar but fails when embedded in an email, API call, or HTML link, an encoding layer mismatch is almost always the root cause.

URL Encode Space: Plus Sign vs %20

Two conventions exist for encoding spaces. RFC 3986 (the URI standard) encodes spaces as %20 in all URL components. The HTML form submission standard (application/x-www-form-urlencoded) encodes spaces as + (plus signs) specifically in query strings. Most server-side frameworks decode both correctly, but some custom parsers handle one but not the other. In URL path segments, always use %20 because + represents a literal plus sign in the path, not a space. In query strings, either + or %20 is technically correct but %20 is universally safe. When you url encode space characters, the tool uses %20 by default for maximum compatibility across all URL positions and all server implementations.

URL Encoding in Python, PHP, and Java

Python: urllib.parse.quote() for path encoding (preserves /), urllib.parse.quote_plus() for query values (spaces become +). PHP: rawurlencode() for RFC 3986 (spaces become %20), urlencode() for form-style (spaces become +). Java: URLEncoder.encode(value, StandardCharsets.UTF_8) for query values (spaces become +); for path segments, use URI constructor or a library like OkHttp that handles encoding correctly. JavaScript browser: encodeURIComponent() for values, encodeURI() for full URLs. Each language pair mirrors the same conceptual split between path-safe and form-safe encoding, and choosing the wrong function in any language produces the same category of double-encoding or under-encoding bugs described above.

Frequently asked questions