URL Encode / Decode

URLs were designed in an era when ASCII was king, and that legacy still shapes how we handle web addresses today. RFC 3986 defines the syntax for Uniform Resource Identifiers, and one of its most practical aspects is percent encoding — the mechanism that allows any character to appear safely in a URL. The need for encoding arises because certain characters have structural meaning in URLs. The question mark separates the path from the query string. The ampersand separates query parameters. The hash marks a fragment identifier. If your actual data contains these characters, they must be encoded to avoid ambiguity. A practical example: suppose you're building a search URL where the user typed "Tom & Jerry". Without encoding, the URL https://example.com/search?q=Tom & Jerry would break — the browser would interpret "& Jerry" as a second parameter named "Jerry" with no value. The correct URL is ?q=Tom%20%26%20Jerry, where %20 replaces spaces and %26 replaces the ampersand. Internationalized domain names (IDNs) and paths add another layer. When you see a URL with Chinese, Arabic, or Cyrillic characters in the address bar, the browser is actually displaying the decoded form for readability. Under the hood, each non-ASCII character is UTF-8 encoded and then percent-encoded. Domain names use a separate scheme called Punycode for internationalization. One of the trickiest aspects of URL encoding in practice is double encoding. If middleware or a framework encodes a value that was already encoded, you end up with %2520 instead of %20 (the % itself gets encoded). This is a frequent source of 404 errors and broken links. Always know which layer of your stack is responsible for encoding, and encode exactly once. When building web applications, the golden rule is: encode values at the point of URL construction, not before. Store raw data and encode only when assembling the final URL string. This prevents the double-encoding trap and keeps your data layer clean.