URL Encode and Decode Query Strings

URL encoding (percent-encoding) replaces reserved characters with %HH bytes so query strings and path segments stay valid. The everyday rule: encode values with encodeURIComponent-style rules; do not blindly encode an entire URL or you will break :// and /.

What to encode

Character	Why it matters
Space	Becomes %20 (forms may use +)
& =	Separates parameters
#	Starts the fragment
Non-ASCII	Must be UTF-8 percent-encoded

Encode vs decode workflow

1. Open TryDevSnip URL Encode (and decode as needed).
2. Encode each query value separately, then join with &.
3. Decode when reading logs or debugging a redirect.
4. Watch for double encoding (%253A means % was encoded twice).

Privacy one-liner: encoding runs in your browser; not uploaded to our servers for processing.

Sibling tools: Base64 for opaque payloads, HTML Entities for markup escaping (different problem).

The characters that actually cause bugs

Most encoding failures trace back to a handful of characters that mean something structural in a URL:

Character	Encoded	Why it breaks things raw
space	%20 (or + in form data)	Truncates the URL in many parsers
&	%26	Starts a new parameter — splits your value in two
=	%3D	Separates key from value
?	%3F	Starts the query string
#	%23	Starts the fragment — everything after it is never sent to the server
+	%2B	Decoded as a space in form-encoded data
/	%2F	Reads as a path separator

The # case is the nastiest, because nothing errors: the server simply receives a silently truncated value, since fragments are client-side only. A value containing & is similar — it arrives as two parameters and the second half quietly disappears.

Encode the parts, never the whole URL

The most common mistake is running an entire URL through an encoder. That mangles the ://, the slashes, and the ?, producing a string that is no longer a URL at all.

Encode each value individually, then assemble:

WRONG:  encode("https://x.com/s?q=a&b")
RIGHT:  "https://x.com/s?q=" + encode("a&b")

In JavaScript this is the difference between encodeURI (escapes only what is illegal anywhere, leaves URL structure intact) and encodeURIComponent (escapes structural characters too). For a query-string value, you almost always want encodeURIComponent.

Double encoding

Encoding an already-encoded string turns %20 into %2520, because the % itself gets escaped. The symptom is a literal %20 visible in the final output instead of a space. It usually means two layers of code are both being helpful — a framework encoding on the way out and your code encoding first. Decode once and check what you actually have before adding another pass.

Real-world example

Suppose a search term is shirts & shoes. Encoded as a query value it becomes shirts%20%26%20shoes (or with + for spaces in form encoding). Leaving & raw splits the query into extra parameters and breaks the search. Encode the value, keep ?q= and &page= structure intact, then decode only when you need to read a log line.

FAQ

Should I use encodeURI or encodeURIComponent?

encodeURIComponent for query values and path segments. encodeURI for a full URL you mostly trust already — it leaves :?&= alone.

Why does + appear instead of %20?

application/x-www-form-urlencoded historically uses + for spaces. Decoders must treat them as spaces in that context.

Can I decode a full page URL?

Yes, but decode carefully — only the parts that were encoded. Blind decode can confuse already-plain text.

Does encoding protect secrets in URLs?

No. Query strings still show in logs, history, and Referer headers. Prefer headers or POST bodies for secrets.