Every URL you've seen with %20 or %3D contains percent-encoded characters. URL encoding (also called percent-encoding) is the mechanism that allows non-ASCII characters and reserved characters to appear safely in URLs. Here's a complete reference for which characters need encoding and why.
How Percent-Encoding Works
Each character is represented by its byte value in hexadecimal, preceded by a percent sign. Space is byte 32, which is 20 in hexadecimal, so it becomes %20. The at-sign @ is byte 64 (40 hex), so it becomes %40.
A URL is processed byte-by-byte. Characters that are safe in a URL are left as-is. Characters that would be ambiguous or invalid are percent-encoded before the URL is sent to the server.
Characters That Must Be Encoded
These characters have special meaning in URL structure and must be encoded when used as data values:
?→%3F— marks start of query string&→%26— separates query parameters=→%3D— separates parameter name from value#→%23— marks start of fragment+→%2B— sometimes decoded as space in query strings/→%2F— separates path segmentsspace→%20or+depending on context
Characters That Are Safe (No Encoding Needed)
These characters are safe to use in URLs without encoding:
- Letters A–Z and a–z
- Digits 0–9
- Hyphen
-, underscore_, period., tilde~
Everything else should be encoded when used as data (not structure) in a URL.
Common Real-World Examples
Search query with spaces: /search?q=word+counter or /search?q=word%20counter — both work; + is the older form, %20 is the RFC-compliant form.
Email in query string: ?email=user%40example.com — the @ must be encoded or the server might misparse the URL.
Tracking parameter with URL as value: ?redirect=https%3A%2F%2Fexample.com%2Fpage — the nested URL has its own :// and / encoded to prevent confusion with the outer URL structure.
Double Encoding: A Common Mistake
Double encoding happens when already-encoded content is encoded again. %20 becomes %2520 (the % is encoded to %25). The result is a URL that appears to work but passes garbled data to the server. Check for this when debugging URLs that contain other URLs as parameters.
To diagnose: paste the URL into a URL decoder and see if the output looks like another percent-encoded string. If it does, you have double encoding. Decode once to get the correctly encoded URL.
Try the Free Tool
Convert URLs to percent-encoded format and back — instantly, in your browser.
Encode or Decode a URL →Frequently Asked Questions
What does %20 mean in a URL?
%20 is the percent-encoded representation of a space character. Space is byte 32 in ASCII, which is 20 in hexadecimal. URLs cannot contain literal spaces, so spaces are always replaced with %20 (or + in query strings).
What is the difference between %20 and + in URLs?
Both represent a space, but in different contexts. %20 is used anywhere in a URL. The + sign represents a space only in query strings (the part after ?). In URL paths, + is a literal plus sign. When in doubt, use %20 — it's unambiguous everywhere.
Do I need to encode forward slashes in URLs?
Only when the slash appears as data, not as a path separator. A URL like /page/subpage uses literal slashes as structure. A URL like /redirect?url=https://example.com/page needs the slashes in the nested URL encoded: /redirect?url=https%3A%2F%2Fexample.com%2Fpage.
What is URL decoding?
URL decoding reverses percent-encoding: it converts %20 back to space, %26 back to &, etc. You'd decode a URL when displaying it to a user, when parsing query string values, or when debugging why a URL appears garbled.
What characters are safe in a URL without encoding?
Unreserved characters are safe without encoding: A–Z, a–z, 0–9, hyphen (-), underscore (_), period (.), and tilde (~). Everything else — spaces, special characters, non-ASCII — should be percent-encoded.