URL Encoder / Decoder

Do not encode a whole URL with the Full mode

The mistake almost everyone makes once, and the reason this tool has more than one mode.

Paste https://example.com/search?q=hello into a standard encoder and you get back:

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello

Which is not a URL any more. The ://, the slashes and the ? have all been encoded, so nothing will treat it as an address. It is a perfectly correct result and completely useless, because that mode is designed to encode a value going inside a URL, not a URL itself.

The distinction is the whole thing:

Full is for one piece of text that will become part of a URL — a search term, a filename, a redirect target. It encodes everything unsafe, including :, /, ? and &, which is exactly what you want when that text is going into a parameter and must not be mistaken for URL structure.

Partial leaves the structural characters alone and encodes only what is genuinely unsafe. Use it when you are handling something that is already a URL or part of one.

Full URL mode is the one to reach for when you simply have a URL with a space or an accented character in it and want it fixed. It encodes the unsafe characters and leaves ://, ?, & and = intact — so you get a working URL back rather than a mangled string. Most encoders have no equivalent.

The redirect-parameter case, which is where Full earns its place

The one situation where encoding an entire URL is correct, and it is worth being clear about because it looks like a contradiction.

If you are putting a URL inside another URL — a ?redirect=, a ?url=, a callback, a tracking destination — then that inner URL must be fully encoded, slashes and all. Otherwise its & characters will be read as separators for the outer URL's parameters, and everything after the first one will be lost or attached to the wrong place.

So: Full for a URL going inside a parameter. Full URL mode for a URL you are about to use. Same input, different jobs, opposite answers.

Spaces: %20 or + ?

Both are correct, in different places, and mixing them up is the second classic bug.

In a URL path or query string, a space is %20. That is what the Full, Partial and Full URL modes produce.

In form data — the body of a submitted HTML form, or a query string built the way forms build them — a space is +. That is a separate, older convention, and it is what the Form data mode produces.

Which means a literal plus sign in form data has to be encoded as %2B, or it will be read as a space. This is a genuinely common source of bugs: a phone number entered as +44 20 7946 0958 arrives at the server with the plus turned into a space if it was not encoded properly.

Decoding here handles both. The decoder converts + to a space first and then decodes the percent escapes, so a string produced either way comes back correctly — which is more than a strict percent-decoder does.

What gets encoded and what does not

A handful of characters are safe everywhere and never need touching: letters, digits, and - _ . ~. Everything else is either reserved — it means something structural, like / ? & = # — or unsafe, like a space, a quote or a bracket.

Non-English characters are worth a note. An Arabic, Chinese or accented character is encoded as several percent escapes, not one, because it is first converted to UTF-8 bytes and each byte becomes its own %XX. So a short phrase in a non-Latin script produces a surprisingly long encoded string — that is correct, not a fault. The character-count readouts on each box make it visible.

The # is the one that catches people. It marks the start of a fragment, so anything after it is never sent to the server. A URL with an unencoded # inside a parameter value silently loses everything from that point on.

When the output looks wrong

Three quick diagnoses.

Everything is %-escaped including the slashes: you used Full on a whole URL. Switch to Full URL mode.

Double-encoded — you can see %2520 or %253A — means an already-encoded string was encoded again. %25 is an encoded percent sign, so it is the signature of a second pass. Decode once and start from the original.

Decoding produces gibberish or an error: the string is probably not percent-encoded at all. If it is a long run of letters, digits and perhaps = at the end, it is likely Base64 rather than URL encoding, and a Base64 decoder is the tool you want.

Nothing leaves your browser

The encoding and decoding happen on your own device, with nothing transmitted. Worth having, because the strings people encode and decode are frequently API endpoints with keys in them, callback URLs, tokens in query parameters and internal addresses — none of which belongs in a stranger's request log.

Related tools

Base64 Encoder handles the other encoding you will meet constantly, and Base64 Decoder reverses it — useful when a string turns out to be Base64 rather than percent-encoded. Hash Generator is what you want when you need something one-way rather than reversible.