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).

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.