URL Encoder & Decoder

What is URL encoding?

URL encoding — formally called percent-encoding — is the process of converting characters into a format that can be safely transmitted inside a Uniform Resource Identifier. RFC 3986 defines a small set of characters that are allowed in URLs without escaping (letters, digits, and -._~); every other character must be encoded. The encoding rule is simple: take the UTF-8 byte value of the character and write it as %XX, where XX is the two-digit uppercase hexadecimal value of that byte. A space becomes %20, a pound sign becomes %23, and a Chinese character whose UTF-8 representation spans three bytes becomes three %XX sequences. Developers, QA engineers, and anyone building or debugging web applications encounter percent-encoding constantly.

When do you need to URL-encode?

Any time a string crosses a boundary where raw characters would be misinterpreted, you need to encode url content before it travels. Common situations include:

• Query parameter values (?q=hello+world) — an unencoded & or = in a value splits the parameter prematurely.
• URL path segments containing spaces, slashes, or Unicode — a literal / inside a segment looks like a path separator to the server.
• Fragment identifiers (#section-2) — special characters confuse the browser's scroll-to-anchor logic.
• Form submissions using application/x-www-form-urlencoded — the browser encodes the form data before posting, but when constructing requests manually you must do it yourself.
• Dynamically built links in code where user-supplied input might contain reserved characters — failing to encode here is a common source of broken redirects and subtle bugs.
• Sharing URLs in email, Slack, or logs — many clients mangle bare special characters; encoding makes the link survive copy-paste intact.

encodeURIComponent vs encodeURI — the footgun

JavaScript ships two built-in encoding functions and they are not interchangeable. encodeURI is designed for encoding a complete URL. It leaves reserved characters like :/?#[]@!$&'()*+,;= untouched because they are structurally meaningful in a full URL. encodeURIComponent, by contrast, encodes all reserved characters — it treats its input as an opaque value, not a URL. That makes it the right choice 95% of the time, specifically when you are encoding a query string encoder value, a path segment, or any other piece of a URL rather than a whole one.

The footgun: using encodeURI on a query parameter value silently breaks URLs that contain & or =. Those characters look fine to encodeURI because they are legal in a full URL, but inside a query value they split your parameter in two. This tool uses encodeURIComponent for that reason.

// WRONG — encodeURI leaves & and = alone inside a value
encodeURI("price=10&discount=5")
// → "price=10&discount=5"   (broken as a query value)

// CORRECT — encodeURIComponent encodes all reserved chars
encodeURIComponent("price=10&discount=5")
// → "price%3D10%26discount%3D5"   (safe inside ?q=…)

Reserved characters quick reference

The table below lists the characters most often encountered in percent-encoded strings and their encoded forms. Note that + deserves special attention: in the legacy application/x-www-form-urlencoded format a + means space, so a literal plus sign must be encoded as %2B. This discrepancy between form-encoded and RFC 3986 percent-encoding is a frequent source of confusion.

• Space → %20
• ! → %21
• # → %23
• & → %26
• + → %2B
• / → %2F
• = → %3D
• ? → %3F
• @ → %40

How to use this URL encoder and decoder

1. Paste the string you want to process into the Input box on the left. This can be a raw query parameter value, a full URL fragment, or an already percent-encoded string you want to decode.
2. Click Encode to percent-encode the input using encodeURIComponent, or Decode to convert a percent-encoded string back to its original characters using decodeURIComponent.
3. The result appears on the right. Click Copy to put it on your clipboard.
4. Use Swap to move the output back into the input box — convenient for round-trip testing or chained operations.
5. Click Clear to reset both boxes and start fresh.
6. If decoding fails, an inline error tells you why — typically a malformed % sequence such as a lone % with no following hex digits.

Example

Encoding a query string value with special characters

Input:  Hello World! Price = $9.99 & tax=0
Output: Hello%20World!%20Price%20%3D%20%249.99%20%26%20tax%3D0

Decoding a percent-encoded search query

Input:  caf%C3%A9%20menu%20%E2%98%95
Output: café menu ☕

Frequently asked questions

Is my data sent anywhere?

No. All encoding and decoding happens entirely in your browser. The tool calls the browser's built-in encodeURIComponent and decodeURIComponent functions locally — no network request is made with your input, and nothing is logged or stored. You can paste API keys, internal links, or any sensitive strings without concern.

Why does my decoded string look wrong or show an error?

The most common cause is a malformed percent sequence. Valid sequences are exactly three characters: a % followed by two hexadecimal digits (0–9 and A–F). A lone % at the end of the string, a % followed by a non-hex character like %ZZ, or an incomplete multibyte UTF-8 sequence (for example, only the first byte of a two-byte character) will all trigger a decode error. Copy the raw string carefully — extra spaces or truncation during copy-paste are the usual culprits.

Does it handle Unicode and emoji?

Yes. encodeURIComponent converts each character to its UTF-8 byte representation first, then percent-encodes each byte. A single emoji like ❤ is four UTF-8 bytes and becomes four %XX triplets. decodeURIComponent reverses the process in the same way, so any Unicode text round-trips cleanly.

What's the difference between URL encoding and Base64?

They solve different problems. Percent-encoding makes arbitrary text safe inside a URL by replacing non-URL characters with %XX escape sequences. The output is still recognisable — a short word becomes a handful of %XX groups. Base64 encoding converts arbitrary binary data into a compact alphabet of 64 printable characters; the output looks nothing like the input and can be substantially longer for short strings. Use percent-encoding for URL components; use Base64 when you need to embed binary data (images, certificates, tokens) inside a text-only channel.

Should I use this for passwords or secrets?

URL encoding is not encryption. Anyone can decode a percent-encoded string with a single function call — there is no key and no secret. Do not use percent-encoding to protect passwords, tokens, or confidential data. If you need to transmit sensitive information securely, use proper encryption (TLS in transit, AES or similar at rest). Percent-encoding only makes characters URL-safe, nothing more.

Does this tool support URL-safe Base64?

No — URL-safe Base64 and percent-encoding are entirely different schemes. URL-safe Base64 replaces + with - and / with _ so that Base64 output can appear in a URL without further escaping. This tool only performs RFC 3986 percent-encoding. If you need to encode or decode URL-safe Base64, use the Base64 encoder instead.