Guide
URL Encoding Explained
URL encoding keeps URLs unambiguous when values contain spaces, symbols, separators, or non-ASCII text.
This technical source review checks guide claims against current standards, official documentation, and the behavior of DevPouch tools. It is not an independent security audit.
Related tools
Reserved characters
URLs use characters such as ?, &, =, /, :, and # as syntax. When those characters are part of a value instead of the URL structure, they need encoding so parsers do not misread them.
Query string values
Query parameters are a common place for bugs. If a value contains an ampersand and it is not encoded, the server may treat it as the start of another parameter.
Use component encoding for individual values. Use full URI encoding only when you already have a complete URL and want to preserve URL separators.
Spaces, plus signs, and percent encoding
Percent encoding represents bytes with sequences such as %20. Form-style query encoding often represents spaces as plus signs. A literal plus sign and a space can therefore be confused if code decodes with the wrong assumptions.
Common bugs
- Encoding an entire URL as a component and turning every separator into percent escapes.
- Forgetting to encode redirect URLs nested inside query parameters.
- Double-encoding an already encoded value.
- Decoding a malformed percent sequence without error handling.
Component versus full URL
Value: red & blue/green
Component: red%20%26%20blue%2Fgreen
Full URL: https://example.test/search?q=red%20&%20blue/green
Encode each query value before assembling the full URL.Boundary checks
- Test spaces, literal plus, percent, slash, ampersand, equals, fragment, and Unicode.
- Reject malformed percent triplets during decode.
- Avoid decoding the same component twice.
- Use form-style plus-to-space behavior only for form/query contexts that define it.
Encode components before assembly
A URL contains structural separators: colon introduces a scheme, slash separates path segments, question mark starts a query, ampersand separates query pairs, equals separates a name and value, and hash begins a fragment. Encoding an entire URL as one component hides those separators. Leaving a component unencoded lets data characters be mistaken for structure.
Build a query by encoding each name and value independently, then join the encoded pairs. The URL and URLSearchParams browser APIs are often safer than manual concatenation because they keep structure and data separate.
Plus signs and repeated decoding
encodeURIComponent represents a space as %20 and a literal plus as %2B. HTML form-style query encoding commonly represents a space as plus. A generic percent decoder does not always translate plus, so the correct behavior depends on how the input was produced.
Decode exactly once at a well-defined boundary. If %252F is decoded twice, it becomes a slash even though the first decoding produced the literal text %2F. Repeated decoding can alter routing and validation decisions and has caused security defects in proxies and application stacks.
Interoperability cases
- Unicode text in path segments and query values.
- Literal percent, plus, slash, ampersand, equals, question mark, and hash.
- An already encoded value to detect accidental double encoding.
- Malformed percent triplets and invalid UTF-8 sequences.
- Empty names, empty values, and repeated query parameters.
- Normalization differences between proxies, frameworks, and application routers.
References
FAQ
Should I use encodeURI or encodeURIComponent?
Use encodeURIComponent for values and encodeURI for complete URLs where separators should remain as URL syntax.
Why does plus sometimes decode to a space?
That behavior comes from form-style query encoding, not from percent decoding in every context.