URL Encoder & Decoder: The Complete Guide

What is URL Encoding?

URL encoding, also known as percent-encoding, is a mechanism for converting characters into a format that can be transmitted over the internet. URLs can only be sent using the ASCII character set, and many characters — spaces, punctuation, and non-Latin letters — are either not allowed or have special meanings within a URL.

When you see %20 in a URL, that is a URL-encoded space. The % sign is followed by two hexadecimal digits that represent the byte value of the character. Spaces become %20, exclamation marks become %21, and so on. This system allows arbitrary binary data to be safely embedded in URLs without breaking the URL parser.

URL encoding is defined in RFC 3986 and is universally supported by all web browsers, servers, and HTTP libraries. Every time you submit a form or click a link containing special characters, your browser encodes them automatically.

Reserved & Unsafe Characters

Characters in URLs fall into three categories: unreserved, reserved, and unsafe. Unreserved characters can be used as-is. Reserved characters have special meaning in a URL and must be encoded when used as data. Unsafe characters are always encoded.

Unreserved Characters

These can be used without encoding: A-Z, a-z, 0-9, -, _, ., ~.

Reserved Characters

Common Encoded Values Cheat Sheet

Encode vs Decode

Encoding and decoding are inverse operations: encoding converts human-readable text into percent-encoded form, and decoding restores the original text from percent-encoded input.

Encoding (Plain → URL-safe)

When you encode a string, every character that is not unreserved is converted to its percent-encoded form. For example:

// Plain text
Hello World! How are you?

// Encoded (encodeURI)
Hello%20World!%20How%20are%20you?

// Encoded (encodeURIComponent)
Hello%20World%21%20How%20are%20you%3F

Notice how encodeURIComponent encodes the ! and ? characters, while encodeURI leaves them as-is because they are valid URL characters outside of query strings.

Decoding (URL-safe → Plain)

Decoding reverses the process. Any %XX sequence is converted back to its original character:

// Encoded URL
https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world

// Decoded
https://example.com/search?q=hello world

When to Encode

URL encoding is required in many everyday web development scenarios:

Query Parameters with Special Characters

If a user searches for "C# tutorial" or "100% free", the # and % characters must be encoded or they will break the URL:

// Broken URL (hash interpreted as fragment)
https://example.com/search?q=C# tutorial

// Correctly encoded
https://example.com/search?q=C%23%20tutorial

Form Submissions

HTML forms with method="GET" automatically encode all field values before sending. The browser converts spaces to + and encodes special characters. This is the application/x-www-form-urlencoded format.

API Calls with Dynamic Values

When building API URLs dynamically, always encode user-supplied values:

const query = "coffee & tea";
const url = `https://api.example.com/search?q=${encodeURIComponent(query)}`;
// Result: https://api.example.com/search?q=coffee%20%26%20tea

Non-ASCII Characters and Emoji

URL encoding handles Unicode characters by encoding their UTF-8 bytes:

// Emoji in URL
encodeURIComponent("café ☕")
// Result: caf%C3%A9%20%E2%98%95

Redirect URLs

When passing a redirect URL as a parameter (e.g., ?next=/dashboard), encode the entire nested URL to avoid parsing errors:

// Nested URL parameter
const redirect = "https://example.com/page?ref=source";
const url = `/login?next=${encodeURIComponent(redirect)}`;
// Result: /login?next=https%3A%2F%2Fexample.com%2Fpage%3Fref%3Dsource

Practical Examples

Debugging an OAuth Callback

OAuth flows often pass complex state objects and redirect URLs as query parameters. A mis-encoded callback URL will fail silently. Use the URL decoder to inspect what the server actually receives:

// Raw callback URL
https://yourapp.com/callback?code=abc123&state=%7B%22csrf%22%3A%22token%22%7D

// Decoded state parameter
{"csrf":"token"}

Building a Search Page with Filters

When building a product search with multiple filters (category, price range, tags), each value must be independently encoded:

const params = {
  q: "wireless mouse",
  category: "electronics & gadgets",
  price: "under $50"
};

const query = Object.entries(params)
  .map(([k, v]) => `${encodeURIComponent(k)}=${encodeURIComponent(v)}`)
  .join("&");

// Result:
// q=wireless%20mouse&category=electronics%20%26%20gadgets&price=under%20%2450

Decoding Logs for Analysis

Server logs store URLs in encoded form. When analyzing traffic patterns, decoding the URLs makes them human-readable:

// Raw log entry
GET /search?q=react+hooks+%26+state&sort=newest

// Decoded
GET /search?q=react hooks & state&sort=newest

Best Practices

• Always encode dynamic values: Any user-supplied string that becomes part of a URL must be encoded. Never concatenate raw user input into URLs.
• Choose the right function: Use encodeURIComponent() for query parameter values and encodeURI() for full URLs. Mixing them up is a common source of bugs.
• Decode before displaying: If you show URLs to users (e.g., in an admin panel), decode them first. Percent-encoded URLs are hard to read.
• Beware of double encoding: Applying encodeURIComponent() to an already-encoded string will encode the % signs, turning %20 into %2520. Always check if the value is already encoded.
• Handle + vs %20: In query strings, + represents a space (legacy from form encoding). In path segments, spaces must be %20. Know which context you are working in.
• Use the tool: When in doubt, paste your text into the encoder/decoder to see exactly how it will be transformed before writing production code.