URL Encoder / Decoder

API DECODE DEVELOPER ENCODE URL

By AI Tools Desk

About this tool

Encode and decode URLs and query strings instantly — with full RFC 3986 component support.

Encode and decode URLs and query strings instantly — with full RFC 3986 component support. Full URL and component modes. Free, no signup.

RT-DEV-010 · Developer Tools

Full URL mode — encodes only what needs encoding; preserves scheme, host, path and reserved characters. Uses encodeURI().

Input URL

Encoded Output

Component mode — encodes the entire input as a single value, including /, ?, & and :. Use for individual query parameter values. Uses encodeURIComponent().

Input Value

Encoded Output

Paste any percent-encoded URL or value. Decodes using decodeURIComponent() with a decodeURI() fallback for partial or reserved-char sequences.

Treat + as a space (form data) Off (the default) is strict RFC 3986, where + is a literal plus sign. On decodes application/x-www-form-urlencoded data — the serialisation HTML forms use, in which + stands for a space. +-means-space is a form-encoding convention, not a URI one.

Encoded Input

Decoded Output

Processed locally in your browser. Nothing sent to any server.

Quick Reference — Component mode

Exactly what this tool's Component mode (encodeURIComponent()) produces. Full URL mode (encodeURI()) encodes only the space in this list — it leaves every other character below untouched, because those characters carry the URL's structure.

Space→%20

&→%26

=→%3D

+→%2B

/→%2F

?→%3F

#→%23

@→%40

:→%3A

,→%2C

!→!unchanged

~→~unchanged

The last two rows surprise people. ~ is an unreserved character in RFC 3986 §2.3, which says percent-encoded forms of unreserved characters "should not be created by URI producers" — so a conforming encoder must leave it alone, and %7E is the wrong output. ! is a sub-delimiter (§2.2) that encodeURIComponent() also leaves as-is, along with ', (, ) and *. If you have seen a reference table that percent-encodes both, it was describing application/x-www-form-urlencoded — a different serialisation from the one this tool performs.

How to Use the URL Encoder / Decoder

Choose Encode or Decode mode

Select Encode to convert plain text or URLs into percent-encoded form, or Decode to convert percent-encoded sequences back into human-readable text.

Choose Full URL or Component encoding

In Encode mode, Full URL preserves URL structure (scheme, host, path) using encodeURI(). Use Component for individual query parameter values — it encodes everything including /, ? and & using encodeURIComponent().

Paste your URL or text — the result updates live

Type or paste your input into the text area. The encoded or decoded result appears instantly in the output field below, with no button press needed.

Click Copy to grab the output

Hit the Copy button to copy the encoded or decoded output straight to your clipboard. Use Clear to reset both fields and start fresh.

URL Encoding — Why Spaces and Special Characters Break the Web

Why URLs Can't Contain Spaces: RFC 3986 Explained in Plain English

The internet is built on ASCII — the 128-character set that includes Latin letters, digits and a handful of symbols. URLs were designed in this same era, and the original specification required that every character in a URL belong to a defined "safe" set. When Tim Berners-Lee and colleagues formalised the URL standard, they faced a problem: how do you represent characters that aren't in the safe set, including spaces, Chinese characters, Malay diacritics and symbols like & or = that carry special structural meaning inside a URL?

The answer, codified in RFC 3986 (2005), is percent-encoding. Every character outside the "unreserved" set (A–Z, a–z, 0–9, -, _, ., ~) is converted to a % followed by its two-digit hexadecimal UTF-8 byte value. A space becomes %20. An ampersand becomes %26. An equals sign becomes %3D.

The distinction between encodeURI() and encodeURIComponent() matters enormously in practice. encodeURI() is designed for complete URLs — it preserves reserved characters like /, ?, # and & because they are structural parts of the URL. If you used encodeURIComponent() on an entire URL, those structural characters would be encoded and the URL would break. Conversely, when you are encoding a single query parameter value — such as the value of a utm_campaign tag — you must use encodeURIComponent() because any & inside the value must be encoded as %26, or the server will interpret it as a parameter separator.

For developers building Malay- or Chinese-language URLs for Malaysian or Singaporean audiences, this matters even more. Non-Latin characters are encoded as their multi-byte UTF-8 sequences — the Chinese characters for Singapore ("新加坡") become %E6%96%B0%E5%8A%A0%E5%9D%A1. Each of those three characters is three bytes in UTF-8, and each byte costs three characters once percent-encoded — so three characters in, twenty-seven out.

Query Strings and UTM Tags: A Guide for ASEAN Marketers Who Use URL Parameters

Digital marketing teams across Southeast Asia — at Grab, Gojek, regional banks, and thousands of e-commerce brands — rely on UTM parameters to track campaign performance in Google Analytics. UTM parameters are appended to URLs as query string key-value pairs: ?utm_source=facebook&utm_medium=cpc&utm_campaign=Shopee+11.11+Sale.

That example is worth running through the Decode tab, because it exposes a real fault line. Paste utm_campaign=Shopee+11.11+Sale in and, with the default settings, it comes back unchanged: decodeURIComponent() implements RFC 3986, where + is a literal plus sign and nothing more. Tick Treat + as a space and the same input decodes to utm_campaign=Shopee 11.11 Sale. Both results are correct — they answer different questions. +-means-space belongs to application/x-www-form-urlencoded, the serialisation browsers use for form submissions; the WHATWG URL Standard is explicit that its parser substitutes a space for 0x2B only when parsing form data, and that its serialiser emits + for a space only in that same mode. A URL is not a form, so a tool that silently converted every + to a space would corrupt any value that contains a genuine plus sign.

The more damaging problem arises when campaign names or ad copy contain structural characters. A campaign called "Grab & Gojek Promo" is dangerous: the unencoded & will be interpreted as a query string separator, silently splitting the parameter in two and corrupting your tracking data. The & must be %26 inside any query parameter value.

"A single unencoded & character in a URL query parameter can silently break your API call, split your UTM tracking data, or redirect users to the wrong page — all without any error message."

Google Analytics itself handles many malformed UTMs gracefully, but it does not fix all of them. Broken UTMs can result in traffic appearing under (not set) campaigns or being incorrectly attributed. For ASEAN marketing teams running multi-market campaigns across Singapore, Malaysia, Indonesia and Thailand simultaneously, a single encoding mistake in a UTM-tagged URL template can corrupt weeks of attribution data.

Common URL Encoding Mistakes That Break APIs and How to Fix Them Fast

Every REST API that accepts parameters in a query string inherits the same rules, and the same failure modes. RFC 3986 §2.2 defines the reserved characters — : / ? # [ ] @ and the sub-delimiters including & and = — as the ones that carry structural meaning. A reserved character is legal where it delimits, and must be percent-encoded anywhere it is meant as data. Nearly every encoding bug is that one distinction, missed once.

The most common mistake: a developer includes a raw & inside a query parameter value. The server receives two separate parameters instead of one, rejects the request with a 400 Bad Request, and the developer spends an hour checking their authentication headers before realising the problem was a single missing %26.

OAuth callback URLs present a particularly tricky double-encoding scenario. The callback URL itself must be URL-encoded when passed as a query parameter to the OAuth authorisation server — so the https:// in your callback becomes https%3A%2F%2F in the outer URL. Component mode does exactly this in one click; Full URL mode would leave : and / intact and produce a request the authorisation server reads as a truncated parameter.

JWT tokens embedded in URLs also require careful handling. Standard Base64 uses +, / and = characters, all of which have special meaning in URL query strings. The solution is either URL-safe Base64 (which replaces + with - and / with _) or percent-encoding the JWT with encodeURIComponent() — which this tool's Component mode handles correctly in one click.

To debug a 400 Bad Request caused by encoding issues: copy the raw URL, paste it into the Decode tab of this tool, and look for any characters that should be encoded. Then rebuild the URL with the corrected encoded values. Most encoding bugs are visible within seconds once you can see the decoded string clearly.

10 Facts About URL Encoding

RFC 3986 (2005) is the current standard defining URI syntax — it specifies that any character not in the "unreserved" set (A-Z, a-z, 0-9, -, _, ., ~) must be percent-encoded.

The + symbol means "space" in HTML form encoding (application/x-www-form-urlencoded) but is not a space in URL path or query strings — a common source of encoding bugs.

Chinese characters in URLs are percent-encoded as their UTF-8 byte sequences — "新加坡" becomes %E6%96%B0%E5%8A%A0%E5%9D%A1 (3 characters, 9 UTF-8 bytes, 27 percent-encoded characters).

Google Search Console now supports Unicode URLs (IDNs — Internationalized Domain Names) which show human-readable characters in browser address bars but are punycode internally.

RFC 3986 §2.1 fixes the syntax of an escape: a % followed by exactly two hexadecimal digits. That is why a lone % in a value is itself an error — it must be written %25.

RFC 3986 §2.3 names the unreserved set — A–Z, a–z, 0–9, -, ., _, ~ — and says their percent-encoded forms "should not be created by URI producers". Encoding ~ as %7E is a bug, not caution.

The # character in a URL is reserved for fragment identifiers (anchor links) — it is never sent to the server, making it unreliable for tracking and requiring %23 when used as a value.

There is no URL length limit in RFC 3986 — the ceilings you hit are implementation limits in browsers, servers and proxies, and they differ. Check the limit of the specific stack you are calling rather than trusting a universal number.

WhatsApp, Telegram and Line all handle URL-encoded links in messages — proper encoding ensures share links from ASEAN platforms work correctly across all messaging apps.

The mailto: URL scheme requires special encoding — email addresses with + signs (common in Singapore for sub-addressing) must be %2B-encoded in mailto: links.

Frequently Asked Questions

URL encoding (also called percent-encoding) converts characters that are unsafe or reserved in URLs into a % followed by their two-digit hexadecimal UTF-8 byte value. You need it whenever a URL contains spaces, non-ASCII characters (like Chinese or Malay text), or special characters like &, =, # that have structural meaning in a URL. Without encoding, browsers and servers may misparse the URL, causing broken pages, failed API calls, or corrupted tracking data.
%20 is the correct percent-encoding for a space in any URL context (RFC 3986). The + sign represents a space only in HTML form-encoded data (application/x-www-form-urlencoded), such as data submitted via a browser form. In URL query strings and paths, + is treated as a literal plus sign, not a space. When in doubt, use %20 — it works everywhere. This tool always encodes a space as %20, and decodes + as a literal plus unless you tick Treat + as a space (form data) in the Decode panel.
Use Full URL when you have a complete URL you want to make safe to share or embed — it preserves the structural characters (/, ?, &, :) so the URL stays functional. Use Component when you are encoding a single value that will go inside a query parameter — for example, the value of utm_campaign, a search term, or a callback URL. Component mode encodes everything including structural characters, which is correct behaviour for individual parameter values.
Switch to Encode → Component mode and paste your URL into the input field. The tool will encode it using encodeURIComponent(), converting all structural characters like /, ?, & and : into their percent-encoded equivalents. The result is safe to use as a query parameter value — for example, as a redirect_uri in an OAuth flow or a url parameter in a sharing endpoint.
URLs were originally designed to carry only ASCII characters. Non-ASCII characters — including Chinese (CJK), Malay/Arabic script, Thai, and emoji — must be converted to their UTF-8 byte sequences and then percent-encoded before being placed in a URL. Modern browsers do this automatically when you type a URL, but when constructing URLs programmatically (in code, APIs or spreadsheets), you must encode them manually. This tool handles all Unicode characters correctly, including multi-byte CJK sequences.
Switch to Decode mode, paste the percent-encoded URL or value into the input field, and the decoded result appears immediately. The tool first tries decodeURIComponent() and falls back to decodeURI() for sequences that include reserved characters. If the sequence is malformed (invalid %XX codes), an error message is shown.
RFC 3986 defines the "unreserved" characters as: A–Z, a–z, 0–9, hyphen (-), underscore (_), period (.), and tilde (~). These never need to be encoded. Reserved characters like /, ?, #, &, =, @, and : are safe in specific positions within a URL (where they carry structural meaning) but must be encoded when used as literal values within a component.
The most common cause is an unencoded & inside a UTM parameter value. For example, a campaign named "Brand & Awareness" appended as utm_campaign=Brand & Awareness will be parsed as two separate query parameters — utm_campaign=Brand and Awareness — breaking your tracking. The fix is to encode the campaign name with Component mode: "Brand %26 Awareness" becomes safe. Always encode UTM values that contain &, =, +, or non-ASCII characters.
Double-encoding happens when an already percent-encoded string is encoded again. For example, %20 becomes %2520 (the % is encoded as %25). This typically occurs when a URL is encoded twice — once by your code and once by a library or framework. It causes servers to receive the wrong value or fail to match routes. To check for double-encoding: decode the URL in this tool and look for any remaining %XX sequences in the output — if you see them, the string was double-encoded.
100% free, forever. No account, no subscription, no hidden limits. All processing happens locally in your browser using JavaScript's built-in encodeURI(), encodeURIComponent() and decodeURIComponent() functions — nothing is ever sent to a server. RECATOOLS is funded by contextual advertising, not paywalls.

Related News

You may be interested in these recent stories from our newsroom.

View all news →