What is URL encoding, and why does %20 keep showing up?
A URL is really just a plain-text address, but its structure depends on a handful of reserved characters: ? starts the query string, & separates parameters, # marks a fragment, and so on. If your actual text contains a space, an ampersand, or a non-ASCII letter, the browser or server can't tell whether that character is part of your content or part of the URL's structure. Percent-encoding solves this by replacing the ambiguous character with its byte value in hex, prefixed by %.
For example, searching for "running shoes" on a site turns into ?search=running%20shoes in the address bar — the space became %20 so the query string stays in one piece. Modern browsers use UTF-8 for this, so multi-byte characters (accented letters, most emoji) get encoded as two or more %XX groups in a row — that's why "café" turns into caf%C3%A9 rather than a single code.
encodeURIComponent vs encodeURI — which one do I actually need?
&, =, and /. encodeURI() encodes a whole address and leaves those structural characters alone so the URL still works.This distinction trips a lot of people up, and it's the single most common mistake when building links by hand. If you encode a full URL with encodeURIComponent(), the slashes and colon in https:// get mangled into %2F and %3A, breaking the link. If you encode just a search term with encodeURI(), an ampersand inside that term won't get escaped and can accidentally start a new query parameter.
| Input (example) | encodeURIComponent | encodeURI |
|---|---|---|
| running shoes | running%20shoes | running%20shoes |
| a & b | a%20%26%20b | a%20&%20b |
| https://x.com/a?b=1 | https%3A%2F%2Fx.com%2Fa%3Fb%3D1 | https://x.com/a?b=1 |
Rule of thumb: use encodeURIComponent for a single value you're inserting into a query string or path segment; use encodeURI only when you have an entire address and want to preserve its structure while still escaping spaces and unsafe characters within it.
Query strings, building links, and cleaning up tracking parameters
key=value pairs after the ? in a URL, joined with & (e.g. ?color=red&size=42). Parameters like utm_source, gclid, and fbclid are tracking-only and can be safely removed before sharing a link.Parsing a real-world URL usually means separating two different jobs: reading the parameters that were already there, and building a new link with your own parameters. Say you receive a marketing link like this (example values only):
https://shop.example.com/product?color=red&size=42&utm_source=instagram&utm_medium=cpc&fbclid=IwAR123abc
Only color and size affect what the page actually shows — utm_source, utm_medium, and fbclid exist purely so the destination site can attribute the click to a specific campaign or ad platform. Stripping them before you bookmark, forward, or publish the link keeps the URL shorter and doesn't leak which ad or post you clicked. On the flip side, when building a link yourself — say a support form that pre-fills a name and a city — each value needs its own encoding pass before being joined with &, otherwise a comma or space in "New York" would silently corrupt the next parameter.
One extra wrinkle worth knowing: a value can get encoded twice by mistake (e.g. by two different scripts in a pipeline), which produces odd-looking strings like %2520 — that's a literal space (%20) that got re-encoded, since % itself becomes %25. Resolving every layer at once, rather than decoding just once, is what fixes that.
+ and /, a Base64 value that's placed inside a URL sometimes needs an additional layer of URL encoding on top.Encode, decode, parse a URL, build a query string, or strip tracking parameters — free and entirely in your browser.
Try the free URL Encode / Decode tool →