Best Free URL Encoder and Decoder: Encode and Decode URLs Instantly

Why URLs need encoding at all

A URL is only allowed to contain a limited set of characters. Spaces, quotes, angle brackets, non-Latin letters, and symbols like & or # all have either a forbidden status or a reserved meaning inside a URL. Percent-encoding is the escape hatch: any byte can be represented as % followed by its two-digit hexadecimal value. A space becomes %20, an ampersand becomes %26, the em dash becomes %E2%80%94.

Encoding is not obfuscation and not security — it is purely a transport format so that data traveling inside a URL cannot be confused with the URL's own structure.

The mistake that causes real bugs

The classic failure: building a query string by concatenation without encoding the values.

https://example.com/search?q=fish & chips&size=10

The unencoded & inside "fish & chips" splits the parameter in two — the server sees q=fish and a mystery parameter chips. Correctly encoded:

https://example.com/search?q=fish%20%26%20chips&size=10

The same applies to =, # (starts a fragment), + (historically a space in query strings), and % itself (must become %25). If a user can type it, it must be encoded before it enters a URL.

Paste any string into our URL encoder/decoder to encode or decode it instantly — everything runs locally in your browser, so the strings you are debugging (which often contain tokens or personal data) never leave your machine.

encodeURIComponent vs encodeURI — the distinction that matters

JavaScript ships two functions and picking the wrong one is a rite of passage:

• encodeURIComponent encodes everything with special meaning, including /, ?, &, =, :. Use it for values — a query parameter, a path segment, anything embedded inside a URL.
• encodeURI preserves URL structure characters and only encodes what is outright illegal. Use it on a complete URL that just needs illegal characters (like spaces) cleaned up.

Rule of thumb: if you are inserting a piece of data into a URL, it is encodeURIComponent. If you are sanitizing a whole URL someone handed you, it is encodeURI. Using encodeURI on a value silently leaves & and = unencoded — exactly the bug from the previous section.

Decoding: reading URLs like a human

Marketing links, OAuth redirects, and analytics URLs routinely arrive as multi-layer encoded soup:

https://example.com/r?u=https%3A%2F%2Fshop.example%2Fsale%3Fref%3Dnewsletter

Decoded once, the u parameter reveals a full nested URL: https://shop.example/sale?ref=newsletter. Redirect chains sometimes encode twice (%253A → decode → %3A → decode → :), so if a decoded string still contains %XX sequences, run it through again. The decoder makes each pass a single click, which turns unreadable tracking links into plain text you can actually audit.

This is also a practical privacy habit: decoding a link before clicking shows you exactly what destination and parameters you are being sent to.

Encoding reference for the characters you will meet most

Character	Encoded	Notes
space	%20	+ also appears in legacy query strings
&	%26	parameter separator
=	%3D	key/value separator
?	%3F	starts the query string
#	%23	starts the fragment — everything after a raw # never reaches the server
/	%2F	path separator
%	%25	must be encoded first when encoding manually
:	%3A	scheme separator

FAQ

Is percent-encoding the same as Base64? No. Percent-encoding escapes individual characters for URL transport; Base64 re-encodes entire byte sequences into a 64-character alphabet. URLs use percent-encoding; binary payloads use Base64 (sometimes a URL-safe variant).

Why does my decoded string show + instead of spaces? In the query-string convention, + historically means space. Some decoders translate it, some do not — if you see stray plus signs after decoding, that is why.

Does encoding make a URL safe from injection? Encoding prevents structural confusion in the URL. Server-side validation is still required — encoding is a formatting concern, not an authorization or sanitization mechanism.