A session cookie, an authorisation header, a password reset link, a support ticket someone forwarded: the moment you want to know what one says is the moment you would paste it into the first decoder a search turns up. That site now has it. This one works out what the text is, unwraps it layer by layer, and never sends it anywhere, because it has nowhere to send it to.
Examples worth trying:
Each step names what was recognised and what it became. Where more than one reading was possible, the others are listed so you can take a different turn.
The things you want decoded are the things worth keeping. A session cookie is a login. An authorisation header is a key. A reset link works once for whoever has it. A support ticket forwarded to you is somebody else's private business. Every one of those is a thing people routinely paste into a decoder on a site they have never heard of, in a tab they close and forget, because they wanted to read it.
It works out what it is rather than asking you. Text is scored against every encoding it could plausibly be, the most likely one is applied, and then the result is scored again, because encodings arrive in layers: base64 wrapped around gzip wrapped around JSON is an ordinary afternoon. Where two readings are both reasonable, both are offered rather than one being picked silently.
A layer that stops making sense is a layer that stops. Decoding does not continue past the point where the result reads as something rather than as noise, and it never claims to have found meaning in random bytes. When it cannot tell, it says so and shows you the bytes, which is more useful than a confident wrong answer.
Nothing here is decryption. Encoding is a way of writing something down; encryption is a way of keeping it. Base64 is not a secret, hex is not a secret, and neither becomes one by being applied twice. Anything that actually needs a key stays unreadable here, as it should.
It happens in this tab. There is no server behind this page to receive what you paste. Turn the network off and it works exactly as it does now, which for a tool whose input is so often a credential is the only arrangement that makes sense.
Base64 in both alphabets, base32, hexadecimal in several layouts, URL escapes, HTML entities, quoted-printable, JSON web tokens, backslash escapes from most programming languages, gzip and raw deflate, UTF-16, decimal and binary byte lists, international domain names, Caesar shifts including the common one, and numbers that are timestamps. It also chains them, which is where most of the work is.
Because some strings genuinely are more than one thing. A run of letters and digits can be valid base64 and valid hex at once, and only the result tells you which was meant. Rather than guessing quietly, the most likely reading is shown and the others are offered next to it.
No, and nothing can without the key. If a result looks like noise with no structure in it, that is what it is: either encrypted, or compressed in a way not recognised, or simply random. The page says which of those it looks like rather than pretending.
Whether it is text and in what script, whether it is JSON or XML or a known file type, how random it looks, whether it contains invisible characters, and whether any part of it is a date, an address, a key or something that looks like a credential.
Safer than anywhere else that offers to decode it, because this page has no server. It is still a token: if it is live, it is a login, and the safest thing remains not to move it around at all. What this removes is the part where a stranger also gets a copy.