URL Encoder / Decoder

API DECODE DEVELOPER ENCODE URL

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.

Encoded Input

Decoded Output

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

Quick Reference

Space→%20

&→%26

=→%3D

+→%2B

/→%2F

?→%3F

#→%23

@→%40

:→%3A

!→%21

,→%2C

~→%7E

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. Every two-byte character expands to six characters in the percent-encoded form.

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.

The problem arises when campaign names or ad copy contain special characters. A campaign called "Shopee 11.11 Sale" is fine — spaces can be represented as + in form-encoded query strings or as %20 in strict RFC 3986 encoding. But 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

REST APIs are the backbone of modern ASEAN digital infrastructure — from SingPass authentication to GovTech's NDI APIs, from Grab's partner integrations to the Singapore Tourism Board's data feeds. Every one of these APIs accepts parameters as URL query strings, and every one of them requires strict RFC 3986 encoding.

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. Singapore government APIs including SingPass follow strict RFC 3986 compliance and will reject improperly encoded callbacks.

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 (9 characters become 27 percent-encoded chars).

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

UTM parameters were invented by Urchin (acquired by Google in 2005) — utm_source, utm_medium, utm_campaign, utm_term, and utm_content are the five standard parameters.

Singapore's SingPass API documentation explicitly requires all query parameters to be RFC 3986 percent-encoded — non-compliance results in 400 Bad Request errors.

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.

URL length limits vary by browser: Chrome supports ~2MB URLs, but most web servers and CDNs limit URLs to 8,000–16,000 characters.

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 uses %20.
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.