How to Encode URLs Correctly When Links Start Breaking
Broken links often look mysterious at first. A redirect works for some users but not others. A search link stops at the first ampersand. A filename with spaces downloads incorrectly. A non-ASCII path works locally, then fails in production. In most of these cases, the problem is not the link itself. The problem is that the wrong part of the link was encoded, or the right part was encoded with the wrong rule. URL encoding is one of those small technical details that feels invisible when it works and painfully obvious when it does not.
Start by Identifying What You Are Actually Encoding
The most common mistake is trying to encode "the URL" without deciding which part of it is the real input. Sometimes you have a complete URL that already contains its own structure, including scheme, host, path, query string, and fragment. Other times you only have a query parameter value, a path segment, a filename, or a user-entered search term. Those are not interchangeable cases.
If you encode a full URL as though it were a single value, you can destroy its structure. If you fail to encode a value before placing it inside a query string, characters like &, =, ?, or / can be misread as syntax instead of content. That is how links begin to "break" even though every visible piece of text seems correct.
Toolnar's URL Encoder is useful because it makes this distinction explicit. It gives separate support for encodeURIComponent and encodeURI, along with decode mode, smart decode behavior, stats, and local browser-side processing. That makes it a practical debugging step instead of just a reference page for the underlying rules.
Understand the Difference Between encodeURIComponent and encodeURI
This distinction matters more than any other. encodeURIComponent is meant for individual values that will be inserted inside a URL. It encodes nearly everything except basic alphanumerics and a small safe set of punctuation. That means it safely protects special characters that would otherwise break parsing if they appeared inside a query parameter or path segment.
For example, if the value is price=10¤cy=USD, treating that as a raw query parameter value is dangerous because the ampersand and equals sign will be interpreted as URL syntax. Encoding it with encodeURIComponent turns it into a safe single value.
encodeURI, on the other hand, is for complete URLs that already have valid structure. It preserves structural characters like :, /, ?, #, &, and = so the browser can still interpret the URL as a navigable address. It only encodes characters that are illegal or unsafe inside that complete structure, such as spaces and many non-ASCII characters.
A surprising number of broken links come down to one wrong function call.
Know the Failure Modes That Cause Real Bugs
Manual URL assembly is where most encoding problems begin. A developer concatenates a base URL and a user-supplied search term. A query value includes a slash, ampersand, or non-English character. A redirect parameter contains another URL. A filename includes spaces or parentheses. Everything looks fine until the browser, server, or router interprets those characters as delimiters instead of data.
This is why query string values should almost always be encoded individually before insertion. Path segments also need care. If a filename or identifier contains spaces, accents, or reserved characters, it must be encoded before being placed into the path. Header values and downloadable filenames can introduce similar issues when non-ASCII content enters the system.
Toolnar's page highlights these exact use cases: query values, form submissions built manually, path segments, some HTTP headers, and decoding URLs returned by APIs or stored in databases. Those are practical failure points, not theoretical ones.
Decode Before You Guess
When a link arrives percent-encoded and unreadable, many people start editing it immediately. That is often the wrong move. First decode it and inspect what the underlying content actually is. Toolnar's decode mode is helpful here because it attempts decodeURIComponent first and falls back to decodeURI when the input is a full URL whose structural characters would otherwise cause errors. This "smart decode" behavior is useful when you are not certain what form the broken link arrived in.
Decoding is especially important with nested or inherited data. A database field, API response, redirect target, or copied analytics link may already have been encoded upstream. If you do not inspect that first, you can end up double-encoding or half-decoding the string and making the problem worse.
The tool's stats also help more than expected. Seeing the input size, output size, and number of %XX sequences can quickly tell you whether you are dealing with a lightly encoded path, a heavily encoded query, or a string that has probably been encoded multiple times.
Do Not Confuse %20 With +
Space handling is another common source of confusion. In standard percent-encoding, a space becomes %20. In application/x-www-form-urlencoded, which is associated with HTML form submissions, spaces may become +. These are related behaviors, but they are not universally interchangeable.
Toolnar makes this distinction clear in its FAQ: %20 is the standard encoded space used in path segments and with encodeURIComponent, while + is tied to form-encoding conventions and is not produced by this tool. If you are debugging broken paths or hand-built links, assuming that + and %20 behave identically everywhere can lead you in the wrong direction.
This matters most when you are mixing browser APIs, backend frameworks, and manually assembled links. Different layers may decode spaces differently depending on the context. Clear diagnosis begins by knowing which encoding model the string actually belongs to.
Avoid Double Encoding and Partial Encoding
Two bugs appear constantly in production systems: double encoding and partial encoding. Double encoding happens when an already encoded string is passed through the encoder again. %20 becomes %2520, and the link begins to fail or display incorrectly. Partial encoding happens when only some values are encoded while others are concatenated raw, leading to inconsistent behavior depending on the input.
The easiest way to avoid both problems is to encode at clear boundaries. Encode user-supplied values at the moment they become part of a URL. Do not encode entire URLs again unless the whole URL is itself being treated as a single value inside another URL. Likewise, decode only when the string is moving back into human-readable display or application logic that expects raw text.
These rules sound simple, but many link bugs come from blurring those boundaries under deadline pressure.
Use a Browser Tool When the Data Is Sensitive
Link debugging often involves private redirect URLs, API parameters, internal search terms, or user-generated content. That is one reason a browser-side tool matters. Toolnar runs the encoding and decoding locally using the native JavaScript functions encodeURIComponent, encodeURI, decodeURIComponent, and decodeURI, and nothing is transmitted anywhere. When you are inspecting potentially sensitive links, that privacy model makes the workflow safer and faster.
It also removes the temptation to paste messy data into an online scratchpad or build throwaway code just to test one string. For quick diagnostics, local browser execution is enough.
Conclusion
When links start breaking, the fix is usually not guesswork. It is understanding which part of the URL is content, which part is structure, and which encoding rule belongs to each. URL Encoder helps by separating encodeURIComponent from encodeURI, supporting safe decoding, showing percent-encoded sequence counts, and keeping the whole process inside your browser. Once you stop treating every broken link as a generic URL problem, encoding becomes much easier to reason about and much harder to get wrong.