URL decode and encode

What a URL decode actually undoes

A URL is allowed to contain a surprisingly small alphabet. Letters, digits, and a handful of punctuation marks are safe; everything else — spaces, accented letters, ampersands that are part of a value rather than a separator, every emoji, every character in every writing system that is not English — has to be smuggled through as its bytes, written out in hexadecimal and introduced by a percent sign. That is percent-encoding, defined in RFC 3986, and decoding is simply the reverse trip: find a percent sign, read the next two characters as a hexadecimal byte, collect the bytes, and interpret them as UTF-8 text.

That last step is the one most tools skip past, and it is where the interesting failures live. %C3%A9 is not two characters. It is one character —é — spread across two bytes, and decoding the halves separately produces garbage. A four-byte emoji is four percent sequences that mean one glyph. Because UTF-8 has strict rules about which byte patterns are legal, a sequence can be detectably wrong rather than merely ugly, and this tool says which rule was broken instead of handing back a row of replacement characters.

The plus sign, and why two tools disagree about your string

Here is the trap that quietly ruins data every day. There is not one specification called URL encoding. There are three, and they do not agree.

encodeURIComponent escapes everything that could act as a separator, which is what you want for a single value. encodeURI deliberately leaves:, /, ?, #, & and= alone, because it is meant for a whole address rather than a piece of one. And application/x-www-form-urlencoded — the format a browser uses when it submits a form, and therefore the format most query strings are actually in — writes a space as + instead of %20.

So ?q=C++ is a search for the letter C followed by two spaces, while a file path ending in /C++ is a folder genuinely named after the language. Same character, opposite meanings, and a decoder that hard-codes one rule silently corrupts everything governed by the other. A signature parameter is the painful case: base64 contains plus signs, so a signed download link run through a form-rules decoder comes out with spaces where the signature was, and the failure appears later, somewhere else, as a rejected request.

This tool refuses to guess. It counts the plus signs in your input and tells you how many there are, defaults to the reading that leaves them visible rather than the one that silently converts them, and lets you flip between interpretations without retyping. The choice only appears when your string actually contains a plus sign, because a control that cannot change anything is worse than no control.

Double encoding, and why one pass is the honest answer

If your decoded result still has percent sequences in it, nothing went wrong — the string was encoded twice. It happens constantly with redirect parameters: application code encodes a return address, then a framework or a proxy encodes the whole query string again, and %20 becomes %2520 because %25is how a literal percent sign is written.

Plenty of tools loop until nothing is left, which looks helpful and is not. A percent sign can be encoded on purpose, and a decoder that keeps going destroys any string containing one. So this one peels exactly one layer, checks whether another pass would find anything, and tells you before you start reading the output. The second pass is a button you press, not something that happens to you.

Strings that make the browser's own decoder throw

decodeURIComponent("100% free") raises an exception. So does any copy that was cut short in the middle of a multi-byte character. Neither input is exotic — one is a discount, the other is what happens when a URL is selected from a wrapped line in a terminal — and because most tools are a thin wrapper around that one function, both produce either an empty box or your original text with no explanation.

Everything here is decoded as far as it can be. A percent sign that is not followed by two hex digits is treated as a literal percent sign and reported as a note rather than an error, since that is almost always what was meant. A genuinely malformed byte sequence is named for what it is — an overlong form, a surrogate half, a character whose bytes ran out — and given its exact position in the string. Anything that cannot be decoded is left precisely as written. Nothing is dropped, and nothing is replaced with a diamond.

Reading a link instead of just decoding it

Most people who need a decoder are not really asking for one. They are asking what is inside a link — which tracking parameters got appended, where a redirect actually goes, what the campaign name was. So when the input looks like a URL or a query string, it is split into scheme, host, path, parameters and fragment, one row per parameter, each value decoded on its own.

The parameter table deliberately uses form rules while the path above it does not, which means the same plus sign can be shown two different ways in the same address. That is not an inconsistency to smooth over. It is the single most useful thing this tool can teach, and seeing it happen to your own link explains it faster than any paragraph.

What this does not do

It does not validate URLs, follow redirects, or fetch anything. It also does not normalize: new URL() in a browser will lowercase a host, resolve.. segments and re-encode what you gave it, which is exactly wrong when the question is what your string literally contains, so the breakdown is parsed by hand and shows the original.

For building a clean URL in the first place rather than decoding one, theslug generator turns a title into a path segment that never needs percent-encoding at all. If your decoded text still looks wrong, the culprit is often a character you cannot see — a non-breaking space or a zero-width joiner that survived a copy from a document — and the invisible character finder will name it. For tokens rather than links,base64 decode is the sibling tool, and it shares the same view of what an encoding is: a way of writing bytes down, with the question of which characters those bytes represent kept separate and explicit. The background to that question is in what Unicode is andhow UTF-8 differs from ASCII.

Why this needs no server, mechanically

Percent-decoding is arithmetic on a string: scan for a marker, read two hex digits, build a byte, group the bytes into characters. There is no dictionary to consult, no model to run, nothing that a remote machine could do faster or better than the tab you already have open. The JavaScript that performs it is the whole product, which is why your text stays in a variable on this page and no request is made while you type.

That property matters more for URLs than for almost anything else people decode. Query strings are where password-reset tokens, signed download links, session identifiers and API keys tend to end up — and a link is usually pasted into a decoder precisely when someone is trying to work out what those parameters contain. If you want to confirm the claim rather than accept it, the page on verifying local processing shows how to watch for yourself.