Reserved vs. Unreserved Characters
Reserved Characters have special meaning in URL syntax and must be encoded when used as data:
:→%3A(colon – separates protocol and host)/→%2F(slash – separates path segments)?→%3F(question mark – begins query string)#→%23(hash – indicates fragment identifier)&→%26(ampersand – separates query parameters)=→%3D(equals – separates parameter name from value)@→%40(at sign – in authentication)
Unreserved Characters can be used without encoding: A-Z, a-z, 0-9, -, _, ., ~
Encoding Examples
Query String with Spaces:
Original: https://example.com/search?q=hello world
Encoded: https://example.com/search?q=hello%20worldSpecial Characters in Parameters:
Original: https://example.com/api?redirect=https://site.com/page?id=5
Encoded: https://example.com/api?redirect=https%3A%2F%2Fsite.com%2Fpage%3Fid%3D5International Characters:
Original: https://example.com/search?q=café
Encoded: https://example.com/search?q=caf%C3%A9Common Use Cases
API Query Parameters
When building REST API calls, query parameters often contain special characters, URLs, or user input that must be encoded. For example, search queries, filter values, or redirect URLs passed as parameters need proper encoding to prevent breaking the URL structure. Without encoding, characters like & and = would be misinterpreted as parameter separators.
Form Data Submission
HTML forms use application/x-www-form-urlencoded format when submitting data via GET or POST. Browsers automatically encode form field values, but developers need to manually encode parameters when constructing URLs programmatically. This ensures user-entered text with spaces, symbols, or international characters transmits correctly.
OAuth & Redirect URLs
OAuth authentication flows and SSO implementations require encoding redirect URLs passed as parameters. Since redirect URLs themselves contain query strings, double encoding becomes necessary. For example, passing https://app.com/callback?token=xyz as a redirect parameter requires encoding the entire URL so the outer URL structure remains valid.
URL Shortener Services
URL shortening services must encode long URLs before creating short codes. Complex URLs with multiple query parameters, fragments, and special characters require careful encoding to ensure the shortened link correctly expands to the original destination without losing parameters or breaking redirects.
Frequently Asked Questions
What’s the difference between %20 and + for spaces?
Both %20 and + represent spaces, but they’re used in different contexts. %20 is the proper percent-encoding for spaces and works everywhere in URLs. The + symbol is a special shorthand for spaces that only works in query strings (after the ?). For consistency and to avoid confusion, using %20 everywhere is recommended.
Do I need to encode the entire URL or just parameters?
Don’t encode the URL structure itself (protocol, domain, path separators, query string indicators). Only encode the actual data values within the URL—specifically query parameter values, path segments with special characters, and fragment identifiers. Encoding the entire URL would turn structural characters like :// and ? into %3A%2F%2F and %3F, breaking the URL.
Can URL encoding prevent security vulnerabilities?
Proper URL encoding helps prevent certain injection attacks and parsing errors, but it’s not a complete security solution. Always validate and sanitize user input on the server side, use parameterized queries for databases, and implement proper authentication and authorization. URL encoding addresses data transmission issues but doesn’t replace comprehensive security practices.
Related Tools
- HTML Encoder/Decoder – Encode special characters for HTML display
- Base64 Encoder/Decoder – Encode binary data for transmission
- JSON Formatter – Format API response data
- Regex Tester – Test URL parsing patterns
Explore More Developer Tools
View our complete suite of free developer and security tools.
