Paste an obfuscated blob from a macro, a phishing log line, or a suspicious script, and watch it unwind layer by layer: base64, the PowerShell encoded command shape, gzip and deflate, hex, URL encoding, and char code arrays. It decodes and shows you what the payload contains. It never runs it.
Attackers rarely ship a payload in the clear. A malicious macro, a phishing log line, or a dropped script almost always wraps the real command in a few layers of encoding so that a quick glance, and a naive filter, see only noise. The layers are usually reversible and stack in a predictable way. This tool detects each layer, applies it, and repeats until the output stops changing, so the readable core falls out the bottom. It is built for triage: you paste, you read, you move on. Crucially, it only decodes and displays bytes. It contains no eval, runs nothing the payload references, and makes no network request, so looking at a hostile blob here does not run it.
Base64 is the most common wrapper, in both the standard alphabet and the URL safe variant that swaps two characters. After a base64 step the tool inspects the raw bytes. If it sees the classic pattern of a printable character followed by a null byte, over and over, that is UTF-16LE text, which is exactly what PowerShell expects behind its -EncodedCommand and -enc flags. In that case it decodes the bytes as UTF-16LE so the command reads cleanly, rather than as a string riddled with null bytes. Otherwise it decodes as UTF-8.
A payload is often compressed before it is base64 encoded, which both shrinks it and scrambles it past simple keyword matching. After a base64 step the tool checks the first bytes: the gzip magic number 1f 8b, or a zlib header, signals compressed data. It inflates the bytes using the browser DecompressionStream API, so the work stays client side with no library and no upload. Because that API is asynchronous, the decode runs through await and the layer appears once inflation finishes.
Beyond base64 and compression, the tool recognises several lighter wrappers that show up constantly in obfuscated scripts:
0x or \x prefixes.%41%42 style seen in phishing links and request logs.104,105, which decode to the characters at those code points.A escapes used to hide strings inside scripts.The tool stops on its own once no known transform applies, or once a step would leave the output unchanged, so it does not loop forever or invent structure that is not there. Some payloads add a custom or single byte XOR layer, which has no fixed signature to detect safely. When the result still looks non printable, the tool offers a single byte XOR hint: it shows the candidate keys whose output looks most like text, as a suggestion you choose to apply, never a forced guess. You can also pick any single transform from the manual list to take the next step yourself.
Each layer is numbered in the order it was applied, labelled with the transform that produced it, and shows the resulting text. The last layer, marked final, is where peeling stopped. Treat the final text as evidence to read, not a verdict: a deobfuscated command still needs a human to judge intent, and that judgement about what a command is really trying to do is the kind of reasoning an AI security testing approach brings, rather than matching one string. For the broader picture of how encoded inputs slip past filters, the web security glossary and the application security writing are good next stops.