Paste a search query into a URL and you'll see spaces turn into %20, ampersands turn into %26, and the whole thing starts looking like a random string of characters. It isn't random. Percent-encoding is a fixed, reversible scheme, and once you know the rule, the "garbage" becomes readable.
The rule is simpler than it looks
A URL can only safely contain a limited set of characters: letters, digits, and a handful of punctuation marks like -, _, ., and ~. Everything else -- spaces, &, ?, =, non-English characters, emoji -- gets replaced with a % followed by the character's two-digit hex byte value. A space becomes %20 because 20 in hexadecimal is the byte value of the space character in ASCII. An & becomes %26 for the same reason. Decoding just reverses the lookup: read the hex pair, convert it back to the original byte.
This is exactly what JavaScript's encodeURIComponent and decodeURIComponent do under the hood, and it's the same mechanism every web framework uses when it builds or parses a query string.
Why encoding a whole URL breaks it
This is the part that trips people up. If you take a complete URL like https://example.com/search?q=cats and percent-encode the entire string, you don't get a working URL back -- you get https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dcats, with the :, /, and ? all encoded too.
That's because percent-encoding doesn't know the difference between "structural" characters and "data" characters. A / in a path is structural -- it separates segments. A / inside a value you're trying to embed in a query parameter is just data. The encoding function only sees characters, not intent, so it encodes everything indiscriminately when you feed it a whole URL.
The fix is to encode only the piece that's actual data -- the query parameter value, the search term, the filename -- and leave the surrounding URL structure (the scheme, the domain, the slashes, the ? and & separators) alone. Encode the ingredient, not the whole dish.
When you'll actually run into this
A few common cases: building a URL that embeds another URL as a parameter (like a redirect link or a share link), passing user-typed search text into a query string, or debugging why a link with an apostrophe or an accented character in it 404s. If a URL looks like it has extra %XX junk in it where you didn't expect any, something upstream double-encoded it -- encoded a string that was already encoded, turning a % into %25 and compounding the mess.
Reading and building these by hand
You don't need to memorize hex-to-ASCII tables to work with this. Paste a raw string in and encode it to see exactly which characters get touched, or paste an encoded URL in and decode it to read what's actually being sent. It's the fastest way to check whether a broken link is a percent-encoding problem before you go looking anywhere else.